Use response files when running subcommands if needed

[owenv]

Now, when a job is created, it can optionally indicate that it supports using a response file to pass its arguments. Then, ArgsResolver is responsible for checking the argument length and writing out a response file if needed. This ensures that if ArgsResolver lengthens the arguments, this is accounted for properly.

I'm fairly happy with this design, but there's one issue in how it interacts with LLBuild, which is why this is a WIP for now. A couple of the integration tests which pass 500k args run very slowly (~3-4 minutes each). It looks like most of the time is spent in JSONDecoder objc bridging (at least on macOS), which is used to serialize Jobs. This might need to be switched to a faster encoder/decoder.

This PR also makes a few changes to response file tokenization to more closely match the integrated driver.

With this change, two response file integration tests still fail: one due to different sets of files being passed with -primary-file, and another because the c++ and swift drivers use a different tmp dir layout.

[DougGregor]

This is looking good, thank you!

[DougGregor]

@swift-ci please test

[Catfish-Man]

Ideally we should speed up JSONDecoder rather than switching away from it, at least initially.

[owenv]

That makes sense to me, especially since it's going to be awhile before the slow tests are up and running on CI builds. Even if llbuild is just working with byte strings, it's probably worth keeping things human-readable for debugging purposes.