Allow Command to be subclassed by application code

[DaRosenberg]

Summary of changes:

• Makes Command inheritable by changing the implementation of the fluent configuration API
  • Instead of directly instantiating new Command instances, the fluent configuration API now delegates to a contained immutable CommandConfiguration struct. This preserves the immutability and atomicity of the configuration (and the resulting thread safety) while allowing the Command object to be reconfigured.
• Adds additional constructors to Command and clarifies their xmldocs
• Ensures the contained CommandConfiguration is always copied to a local variable up-front to protect against any concurrent modifications
• Changes accessibility of Command.CreateStartInfo() from private to protected virtual to allow derived classes to customize how the ProcessStartInfo is configured
• Fixes StandardInput, StandardOutput, and StandardError properties on ProcessEx to return Stream.Null when not redirected
• Updates unit tests accordingly (all tests are passing)

To avoid any breaking changes, Command still implements ICommandConfiguration but now delegates the implementation to the contained CommandConfiguration instance. This should be removed in next major, and applications should instead use the new Command.Configuration property.

Closes #79

[Tyrrrz]

Thanks @DaRosenberg.
I'll get back to this PR in a bit.

[Copilot]

Pull Request Overview

This pull request enables subclassing of the Command class by refactoring the configuration API to use an immutable CommandConfiguration struct while still supporting reconfiguration on the Command instance.

• Refactors the fluent configuration API to delegate to a contained immutable CommandConfiguration instance.
• Adds additional constructors and xmldocs on Command to support subclassing.
• Updates ProcessEx and Command.Execution to use configuration snapshots to protect against concurrent modifications.

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
CliWrap/Utils/ProcessEx.cs	Updates Standard* properties to return Stream.Null when not redirected.
CliWrap/CommandConfiguration.cs	Introduces the immutable CommandConfiguration record struct and its overload constructor.
CliWrap/Command.cs	Refactors the Command API to update the contained configuration in place and exposes ICommandConfiguration.
CliWrap/Command.Execution.cs	Updates process start info construction by snapshoting configuration and marking CreateStartInfo as protected virtual.
CliWrap.Tests/ValidationSpecs.cs	Adjusts tests to validate against Command.Configuration rather than Command directly.
CliWrap.Tests/ConfigurationSpecs.cs	Updates tests to assert that the same Command instance is mutated by the reconfiguration API.

Comments suppressed due to low confidence (1)

CliWrap/Command.cs:112

• The fluent API methods now mutate the command instance in place instead of returning a new instance, which deviates from a typical immutable design. Please confirm that the mutable behavior is intentional and that any thread-safety implications are clearly documented.

public Command WithTargetFile(string targetFilePath)

[Tyrrrz]

I'll add my comments back in the original issue because there's more context to the discussion there

[Tyrrrz]

As discussed in later comments of #79, this PR is obsoleted by #290 which provides an additional overload of ExecuteAsync(...) that offers extension points for direct process configuration, similar to this PR but via delegates instead of inheritance.