What application consumes this data? The application that is consuming this data is the application I would use to parse it.
If it is to be consumed in Excel, then I'd use Excel to handle it. If it is SSRS, then I'd use SSRS. If it is some home-grown .NET application, then that .NET application.
If the application that is consuming the data can't handle that format, then I would be looking at the application that creates that data and have that push it into the database in the same format it is to be consumed.
If that is not possible, PowerShell can handle this, bat files can handle this (not as nice as powershell mind you), bash scripts, .NET, Excel, etc. It really depends on what you are comfortable working with and how the consuming application takes its input.
I don't think you will find any magic application that you can just give it some input like what you have there and it will give you the output you expect without some form of customization and then it just comes down to what methods of customization are you comfortable working with and where are you comfortable having the workload reside. Maybe the table is small and doing 2 loops in SQL is the best option; maybe you are only running this once per year during slow server times so SQL is an acceptable option. If the table is small and will never ever be large, SQL may be an acceptable answer to your problem.
It also depends on what you are doing with the data once you get it. Does it get exported to a flat file? Is it a query that you are writing for a stored procedure to be called by an application? Is it a Database Developer thought task that will never be used in a production environment? etc.
If one of my application developers asked me for that, I would tell them "here is the data as provided by application XYZ. Parsing this data inside SQL to the format you require is not a good use of server resources. Please parse the data in your application layer." The other advantage of pushing back to the application team is they sometimes change the requirements without thinking of the database side. What if in the future they decide to add in A[a:g] and expect the database to understand that that should include Aa, Ab, Ac, Ad, Ae, Af, and Ag but don't tell you? Now your nice query needs to handle additional requirements (ranges) and you have just introduced a 3rd loop. And what if they introduce ranges AND exclusions like A[a:g^f] which would give the same range as above, but exclude f? Another loop. Eventually the application team will come back and tell you the SQL query is too slow, make it faster and the only way to make it faster is to remove requirements on those loops or reduce the number of rows you are doing the loops on (ie reduce the scope).
Doing those sorts of things inside C# is fairly trivial and with multithreading, can be quite quick to go through even very large lists.