This will be used to provide that information to the optimizer as
well as to user-space through linking info. Therefore, it is an
observable piece of knowledge that belongs to the core spec.

`StructField` is only used for captures, which are always
immutable.

However, it does box `long`s into instances, which means that two
boxed longs are not `===`.

We can selectively reintroduce them later.

The WebAssembly backend and the optimizer are now happy to work
together, so we can enable the latter.

When compiling to Wasm, the optimized implementation we have for
`ArrayBuilder` makes no sense, as it relies on JavaScript arrays.
Therefore, we revert to using the original implementations when
linking for Wasm.

This includes `arraycopy` and `getClass().getName()`, which produce
new `Transient` nodes that we need to handle in the Wasm backend.

The motivation is mainly to get intrinsics for the bit-conversions
between integers and floating point numbers, as well as for
`numberLeadingZeros`. These are building blocks for many other
low-level operations, and their JS-builtin-based implementation is
really bad on Wasm for those use cases.

Once we have the infrastructure for those as transients in the Wasm
backend, we also take the opportunity to add a series of other
methods that have a direct Wasm opcode equivalent.

The implementation based on `FloatingPointBits` is poor for a Wasm
output, as it uses JS interop. Given that we have an intrinsic for
`doubleToLongBits`, we can implement it much more efficiently for
Wasm.

This is important because this function is called to compute the
hash code of all JS `number`s, including those that originate as
`Int`s.

When we resolve a dynamic call to a single possible target, but we
do not inline it, we now replace the `Apply` by an `ApplyStatically`.
This communicates the result of the resolution to the backend, which
can emit a static `call` instead of a vtable or itable-based dispatch.

These were one of two remaining sources of `Apply` nodes that the
backend could turn into `ApplyStatically` but that the optimizer
could not (because they are created after the optimizer).

The optimizer already replaces `Apply` nodes that can be statically
resolved by `ApplyStatically`. The `isEffectivelyFinal` analysis is
therefore not useful anymore.

Technically, it was still applicable to JS property/method *names*
that are not string constants, but that is too niche to justify
keeping the analysis. Also, arguably the correct fix for that would
be to make the optimizer also optimize JS property/method names,
since it would also benefit the JS backend.

`ClassInfo` is now completely immutable.