Document our policy on target architecture soundness

[joshlf]

As described in #61, we pin the soundness of zerocopy and of the code generated by zerocopy-derive only on the Rust reference and standard library documentation. Unfortunately, it turns out that the Rust reference and stdlib docs make guarantees which are not actually upheld on some target architectures. We originally considered attempting to only compile on targets which we could either validate matched the reference or at least which had a promise from Rust that they matched the reference. It turns out that both of those are non-starters.

Instead, this issue tracks:

• Update our docs to describe that our soundness is based on guarantees provided by the Rust reference and stdlib docs.
• Warn that some target architectures may not actually uphold these guarantees, and note that zerocopy may not be sound on such targets.
• Provide a link to this UCG WG issue for context.

[jswrenn]

Given zerocopy's ethos of always, definitely being sound, we should perhaps take the even more conservative route of producing a compile_error on all architectures except the ones we know are sound. That way, we won't have a repeat of this issue if rustc later adds support for another unsupportable architecture.

[joshlf]

Hmm very good point. Want to edit the text/title of this issue to track that broader task? I'm thinking we could change the error message to something that conveys:

• Zerocopy hasn't been proven sound on this target architecture
• That isn't cause for alarm - it just means we haven't gotten around to doing it
• Comment on this issue if you need support a not-yet-supported target

It'd also be good to track potential support by target so we have a place to write the note about SPIR-V so we don't forget and spuriously re-enable support.

Looks like compile_error supports multi-line string literals, but the output is a bit weird - only the first line is colored red, and the rest are black.