Limit alias regions in Wasm-to-CLIF translation to 256

[fitzgen]

Instead of bitpacking the AliasRegionKey into a u32, hash it and then xor-fold the hash down to one byte.

Fixes #14221

Depends on #14230

[gfx]

This fixes the problem I reported in #14210.

I used the generator script from that issue and ran wasmtime compile -o /dev/null. Release build, best of 3, macOS / aarch64 only.

N	base ffb04089ea	this PR
250	0.14 s	0.08 s
500	0.97 s	0.19 s
1000	6.86 s	0.40 s
2000	51.48 s	0.87 s
4000	--	1.79 s
8000	--	4.15 s

Time roughly doubles when N doubles, out to N=8000. The blowup is gone and my
module builds again. Thank you.

FYI, the RPO worklist from #14211 is still 3-5x faster on top of this PR
(0.16 s at N=2000, 1.39 s at N=8000), but the gap narrows as N grows, so it is
only a constant factor now. However, I am closing #14211. It conflicts, and this PR fixes what I actually
hit.

One request: if this misses the 49.0.0 branch on the 5th, could it be
backported to release-48.0.0? The slowdown is a serious regression in 48.0.0, and
48.0.x is the current release. I know patch releases are meant for
security and correctness fixes and that backports are volunteer work, so this
is only a request.

[cfallin]

Review on the last commit only (the lattice commit still has work in progress as I understand it from our discussion yesterday, re: scoped hashmap and such).

My main concern with the machinery here is the description-string complexity. Seeing the "reverse map" that keeps original identities around, and especially the string-joining machinery, inside Cranelift itself, both (i) raises serious efficiency concerns for me (we may be at a net speedup by preventing alias-analysis state blowup, but we are still introducing a lot of string munging to produce strings that most compilations will never need), and (ii) seems more complex than it needs to be.

I wonder if we could simply drop the descriptions, and instead emit log::trace lines for mapping of alias-region keys to Cranelift region numbers, and let that suffice for debugging? It seems that all the same information would be there, but we wouldn't be eagerly computing then throwing it away on every compilation...

[fitzgen]

This is now rebased on main, now that #14230 landed. Should be ready to merge once it has your approval, @cfallin.

[cfallin]

LGTM!

[cfallin]

(There's a clippy failure on a u128 as u64 truncation; I guess it needs a pragma of some sort to placate it)