Add mem::conjure_zst for creating ZSTs out of nothing

[scottmcm]

This adds a new unsafe fn to mem which can create instances of ZSTs (and only ZSTs).

I think this is valuable for a few reasons:

1. It avoids wondering whether it's best to do this with zeroed() or uninitialized() or new_uninit().assume_init() or transmute_copy or ... when you're writing code. (See, for example, this PR conversation Add internal collect_into_array[_unchecked] to remove duplicate code #82098 (comment) )
2. It makes it clearer to the reader of the code what's happening, rather than making them get distracted wondering "wait, why is zero-init okay here?" or similar.
3. It gives a good place to describe the soundness restrictions on this operation, since it's easy to mistakenly think "oh, it's a ZST, I'm sure it's sound to just create one no matter what". (cc @RalfJung , in case you'd like to check whether what I wrote is sufficient.)

TL/DR: I think this is a useful piece of "good evil".

The PR also uses it in a few places in the library I quickly spotted where we need to create instances after size_of::<T>() == 0 runtime checks, if you'd like to see usage examples.

Naming

To conjure is to summon by or as if by invocation or incantation.

Given that we have transmutation already, I thought that conjuration fit well for this operation -- the method is creating it "from nothing", as opposed to the "from something else" of mem::transmute. (This seems a pretty pervasive use, here's a game example of conjuration to add to the previous book one.)

[rust-highfive]

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

[RalfJung]

The docs LGTM.

Currently the function states "size_of::<T>() must be zero" as a safety precondition but also actually checks this condition at runtime. If the intention is that this must be ensured be the caller (i.e., if this truly is a safety precondition), then it might be good to just add an explicit comment in the code saying that the assert! is "because we can" but not a guarantee exposed to clients.

[scottmcm]

One could also think of this method as part of a future set for

(Standard “Zero-Sized-Types get to cheat and lie” caveats apply, although it may be desirable to give them their own API just to make that 100% clear.)

as mentioned in https://doc.rust-lang.org/nightly/std/ptr/fn.invalid.html

For example, there could be unsafe fn conjure_zst_ref<'a, T>() -> &'a T (and _mut) but I'm not going to include that in this PR.

[bors]

☔ The latest upstream changes (presumably #93700) made this pull request unmergeable. Please resolve the merge conflicts.

[JohnCSimon]

Ping from triage:
@scottmcm - can you address the merge conflict

[scottmcm]

I probably need to make an ACP for this now, so I'll just close the PR and decide whether to try again later.

[scottmcm]

(Picking this back up now that the ACP was approved; will need some corresponding updates.)

[hkBst]

@scottmcm seems like this just needs a #[allow(uninit_assumed_init)] to satisfy clippy.

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[Qelxiros]

@scottmcm This hasn't had activity in a while, and I'd like to pick it up. Are you still working on it?

[scottmcm]

@Qelxiros Sure, if you want to take it and run with it, please do!

(Just comment here once you open the new PR so I'll know to close this one.)

[scottmcm]

Obviated by #146479