In bytecodealliance#11682 we see a module with an extremely large single function body
(function index 193). This causes a panic in Cranelift as we run out of
SSA value numbers: the `ValueDataPacked` bit-packing supports only 2^24
(16M) values per function.

I started down the path of propagating `CodegenError`s everywhere
throughout Cranelift to properly bubble up a
`CodegenError::CodeTooLarge`, but that turns out to be an extremely
pervasive change: it means not only that we have more Result plumbing,
but that (i) Cranelift's public API changes so that all function builder
methods return Results, which is a huge change for any existing user;
and (ii) ISLE can't generate Rust that propagates Results, so we need to
awkwardly set an error flag on a context, return a fake Value, and
"catch" it on the other side of the invocation, which is error-prone.

I then considered a size-check on function bodies as they enter
Cranelift, but at that point, realized that Wasm already provides for
implementation limits for this purpose. The JS embedding spec at
https://webassembly.github.io/spec/js-api/index.html#limits specifies
that a function body can be at most 7_654_321 bytes (7.65MB). We don't
*have* to follow the JS embedding's implementation limits, but there is
good reason to expect that producers will try to stay within them, and
the reasons that led to those limits in Web engines' compilers equally
apply to ours. This PR thus instead enforces the limit directly.

Fixes bytecodealliance#11682.