[Feature] Make Configuration, Arguments, and Environment more open for testing purposes

[cmcgee1024]

Is your feature request related to a problem? Please describe.

One of the benefits of generating Subprocess Configuration instead of statically constructing run(_:Executable,arguments:Arguments) is that you can make command-line generators in Swift code that can also be unit tested very nicely without actually spawning processes. The swiftly project makes use of this extensively because there are dozens of different kinds of command-lines that it uses. Actually spawning the processes for each test makes them slower and more brittle.

Inspecting the executable of the configuration is straightforward since the Executable enum is public and the cases can be matched easily. However, the Arguments is entirely opaque to any client module. There's no way to easily iterate over the argument list to verify correctness since the storage is internal. The best that one can use is the description, but it's more difficult to discern argument boundaries and there is some custom text inserted. Being able to iterate the arguments in some way, or even convert it into an array of strings would allow one to check what was provided to the init afterwards for verification purposes.

Similarly, Environment cannot be switched on its internal configuration to determine whether its custom, or inherited and what are the associated value dictionaries assigned to them. The description computed property for the CustomStringConvertible protocol is available, but then it becomes a parsing problem to find specific values in it.

Opening up the OS path key will be good too so that one can pull out any override or customization to the path environment.

Describe the solution you'd like
I would like for Arguments to be iterable as strings that were used to construct it for verification purposes. Also, I would like the ability to decompose Environment as the inherit or custom cases used to construct it along with the associated value dictionaries too. Also, the OS path key so that any custom or overrides to it can be detected. This will make it easier to build unit testing around configuration building for subprocess.

Describe alternatives you've considered
An alternative would be to construct my own configuration-like type that then converts to subprocess configuration later on. But, this would involve considerable duplication. Also, the conversion code would need to be tested on top of the configuration building logic.