Support configurable Windows Job Object assignment

[broken-circle]

Follow-up to #260 where we discussed unconditional Job Object assignment.

On Windows, processes are currently assigned to Job Objects unconditionally. The drawback to this is that assignment can fail when the parent is already in a Job Object that doesn't allow nesting, or when the system otherwise cannot form a valid hierarchy.

This PR adds PlatformOptions.JobObjectAssignment, describing how Job Object assignment is handled. The following behaviors are available:

• .always: Always assign. This is the default, and preserves the existing behavior.
• .bestEffort: Attempt to assign, and proceed without one if assignment fails.
• .never: Never assign. spawn() skips the forced CREATE_SUSPENDED; suspension is used to ensure that processes cannot run before being assigned to a job, but in this case there is no job assignment.

Execution.terminate(withExitCode:toProcessGroup:) will throw processControlFailed if toProcessGroup is true, but the process isn't assigned to a Job Object (.never, or .bestEffort with assignment failure). processControlFailed now gains an optional reason so the user sees a more descriptive reason for the error (no assignment) rather than a generic "Failed to terminate child process" message.

[jakepetroules]

This needs a rebase

[broken-circle]

@jakepetroules Done, rebased onto main.

[iCharlesHu]

I like the direction of this change (thanks @broken-circle)! However, I think we should defer this one to post 1.0. It introduces new concepts to the API surface, and we are currently trying to finalize the 1.0 API. This way, it gives us more time to discuss the right shape of this API, similar to the decision we made in #285.

cc @compnerd: What do you think about this API change? Do you think it's necessary to go in now?

[broken-circle]

@iCharlesHu Great, thanks! For the necessity question: assignment is unconditional today with no opt-out, so if the calling process itself is in a non-nestable job, spawning fails entirely on Windows. I don't have a good sense of how often that comes up in practice, though. If it's fairly uncommon, post-1.0 makes sense.