std: restructure child process namespace

[andrewrk]

Upgrade guide:

-std.ChildProcess+std.process.Child

Some other functions are also moved from std.ChildProcess to std.process namespace.

In the future there will be even more breaking changes. For example, instead of creating a Child and then setting fields on it and then calling spawn, there will be std.process.spawn which takes an "options" parameter and then returns the Child, which is an object that lasts only from spawn until termination. This is a practice that we have been moving more towards in Zig, which is to have types designed to have minimal lifetimes and minimal states with undefined fields.

[kubkon]

Exciting!

[squeek502]

Added a commit that improves the doc comments of some functions since they are now actually exposed (they were pub before but not exposed from any standard library namespace).

I think this is fine as-is, but want to note that while argvToCommandLineWindows/argvToScriptCommandLineWindows/WindowsCommandLineCache are technically usable outside the context of process.Child, not too much thought went into their API for that purpose. IMO it would be equally valid to stick them in process.Child and make them non-pub, but I don't have strong feelings one way or the other.

[andrewrk]

Ah, I didn't realize they were not actually exposed. In that case, I would rather move them into Child.zig and make them private. Is that okay with you?

[squeek502]

Is that okay with you?

Yep, definitely. There are quite a few nuances with them vis-a-vis BatBadBut.

You can leave createWindowsEnvBlock and createNullDelimitedEnvMap in std.process if you'd like, those are unrelated to the Windows argv stuff and likely more generally useful.

[andrewrk]

Crap. I accidentally clobbered your commits @squeek502 - would you mind adding them back?

Edit: never mind, I still have them in my other zig checkout :-)