Add tcast crate with TransparentCast derive

[sffc]

Fixes #7607
Replaces #5101
See #6915

I was trying to use ref_cast, but found that it had multiple deficiencies:

1. Doesn't support standard pointer wrappers like Box
2. Implements a trait by default, which can violate field invariants
   • Note: it supports a private conversion function via RefCastCustom
3. Not highly suited for use as a dev-dependency only

So, I made my own proc macro, TransparentCast.

The use cases are the same as RefCast, as listed in #7607, but it resolves the deficiencies listed above.

I am as sensitive to dependency bloat as everyone else, so I specifically designed this derive to be usable as a dev-dependency. See the example. However, this PR is not intended to be the place to debate whether we decide to use that strategy in icu4x.

[robertbastian]

This does not pull its weight as a dependency. I don't see the point in obsessing over motivated uses of unsafe, and pushing them to other crates.

It also doesn't make sense as a dev-only dependency. That pattern increases complexity a lot and actually removes testing from the unsafe code.

[Manishearth]

FWIW I do plan to look at this, but I haven't had the time.

Overall I think a crate like this is probably useful, but I'm skeptical of how useful it is to ICU4X. From an unsafe review point of view, a smattering of "simple" unsafe usage is far easier to audit than complicated macros and trait setups: "APIs for reducing unsafe" have the problem that they need to be audited for all potential usages ("must be safe no matter what the user throws at it") which is far more challenging than just checking for a repr(transparent) and explicit type annotations. "Number of loc unsafe" is not that meaningful a metric except for in the broadest order-of-magnitude sense.

This is counteracted by popular unsafe code crates sometimes being widely audited and trustworthy though that needs to be weighed against their size.

So: I would support publishing this separately as a general non-ICU4X utility, but without having looked too closely, I do not think we should spend time on this or use this in ICU4X.