library: Make ProcThreadAttributeListBuilder more unsafe

[workingjubilee]

Honestly, I took the "make it all unsafe" approach in this draft because it wasn't clear to me what exactly was the best to do and I figured we'd find out in review.

r? @ChrisDenton cc @PaulDance
Resolves #158601

[rustbot]

ChrisDenton is not on the review rotation at the moment.
They may take a while to respond.

[ChrisDenton]

This one I'll need to think a bit about. Honestly I've gone back and forth, though I fear this is ultimately a libs-api question.

[PaulDance]

Having at least one marked unsafe is better. Having all of them as such could be a bit overkill, though. In any case, I don't have too strong of an opinion on this and the current state is OK I guess.

[ChrisDenton]

Ok, I do think this is a libs-api decision so I'm going to nominate libs-api.

There are two options:

• make Command::spawn_with_attributes unsafe
• make ProcThreadAttributeListBuilder::attribute unsafe

The argument for the former is that generally we say pointers are totally safe right up until the point you do something with them. In this case ProcThreadAttribute should be essentially an opaque key/value store and doesn't dereference anything itself (although this technically isn't guaranteed by the MS documentation I'm not sure there's any practical reason for it to do so).

The argument for the latter is that it'd be nice if ProcThreadAttribute could immediately encapsulate the unsafety so it's the user's job to ensure any pointers inside structs points to memory that lives at least as long as the ProcThreadAttribute's lifetime.