Refactor process spawning with Process.capture

[straight-shoota]

This is a PoC for refactoring app and spec code to simplify the code for spawning subprocesses and capturing their results as part of the discussions crystal-lang/crystal#16657 and crystal-lang/crystal#7171.

The monkey-patched Process.capture and .capture_result methods are a draft variant.
They differ from the proposal in crystal-lang/crystal#16630

Some of the key changes:

• Command strings are transformed into percent array literals. This keeps the diff simple and the code readable (cf. Representation of Process arguments crystal#14773 (comment)).
• Specs test the success status of process results directly, instead of expecting an exception.
• Output and error streams are captured separately.
• shards-specific capture code is shared between resolvers.

[ysbaddaden]

Until we support %W[] then I think being explicit is more readable:

capture ["fossil", "remote-url", "-R", "#{library.name}.fossil", "..."]

The feeling is confirmed for every other cases. An explicit array of strings is leagues better.

[ysbaddaden]

Overall a single array for [cmd, *args] is fine, but Process.new and Process.run shall support the syntax, too.

[straight-shoota]

I suppose this is a pretty subjective preference. IMO array literal + << reads nicer because there's less noise with quotation marks.

capture %w[fossil remote-url -R] << "#{library.name}.fossil" << "https://foss.heptapod.net/foo/bar"
capture ["fossil", "remote-url", "-R", "#{library.name}.fossil", "https://foss.heptapod.net/foo/bar"]

Also, the diff is smaller, and the future diff to %W will also be smaller. So if nothing else, it has patch ergonomics going for it.

[ysbaddaden]

I'm not sure a nilable out/err is very significant over empty strings, so this Result type doesn't bring anything valuable over {status, output, error} tuple.

[straight-shoota]

The main reason for a result type over a tuple is that I find it easier to handle. For example, result = Process.capture(...) feels more convenient than status, output, error = Process.capture(...). It's less fragile, can be well documented, and wrapping it in FailedCommandError seems quite useful.

The nilable values are just a convenience feature on top. I believe it might be helpful sometimes to differentiate between whether the output is empty or we didn't even capture any.

[straight-shoota]

Having a dedicated result type is IMO strictly superior to an implicit tuple type.

It gives full control over it and allows modifications in the future (for example, we could consider making input data such as args and env available).
Ergonomics are also better because we don't rely on implicitly ordered members but named properties.