Collapse run() overloads behind a generic Execution type

[iCharlesHu]

Reduce the 14+ run() overloads to two (one executable-based, one configuration-based) by making Execution generic over its input, output, and error types. The body closure now takes a single Execution<Input, Output, Error>, and type-conditional extensions expose standardInputWriter, standardOutput, and standardError only for the matching stream types.

Companion changes:

• Merge ExecutionOutcome into ExecutionResult<ClosureResult, Output, Error>, which now carries the body closure's return value via closureOutput. Now all run() methods return ExecutionResult. ExecutionOutcome remains as an internal helper.

• Expose CustomWriteInput and SequenceOutput publicly, along with the .inputWriter and .sequence factories. Callers opt in per stream:

  • input: .inputWriter unlocks execution.standardInputWriter;
  • output: .sequence unlocks execution.standardOutput;
  • error: .sequence unlocks execution.standardError.

[iCharlesHu]

Resolves: #249
Resolves: #247

[jakepetroules]

This looks really nice, I think it is a big improvement! Summarizing the 6 overloads, there are 3 axes of variation with 2 possibilities each.

First arg	Input type	Has body: closure?
Executable	Span	No
Executable	InputProtocol	No
Executable	InputProtocol	Yes
Configuration	Span	No
Configuration	InputProtocol	No
Configuration	InputProtocol	Yes

This seems like a fairly reasonable number to me, especially as the overload mechanism no longer relies on the closure arguments.

The only thing I can think of to reduce the overloads further is that you could eliminate the 3 "executable" overloads and have only the "configuration" ones, then move run() from a global to a member of Configuration, which would also address one of the concerns @weissi pointed out w.r.t. global namespace membership. That said, I think that discussion could be had separately from this improvement if that's something you are willing to consider.

[jakepetroules]

I also get compiler warnings about AsyncSequence and nonisolated on Input+Foundation.swift on the write() functions at lines 78 and 132. You should be able to fix this by changing:

for try await data in asyncSequence {

to:

var iterator = self.sequence.makeAsyncIterator()
while let chunk = try await iterator.next(isolation: #isolation) {

but that requires a macOS 15 deployment target. FWIW, I think we could realistically consider raising Subprocess's deployment target to macOS 15 at this point.

[iCharlesHu]

Make ExecutionResult.{standardOutput|standardError|closureOutput} non-conditional and non-optional. For Output with Void OutputType these properties will just be Void, which Xcode correctly warns you about.