Rematerialization

As an alternative to spilling and reloading, a vreg value can sometimes be recomputed from other available values. There are two ways this can be supported in regalloc2:

## Simple rematerialization

Supporting rematerialization for constants, including runtime constants which only depend on pinned registers (e.g. VMContext), is relatively straightforward. The client needs to track rematerialization metadata for each `VReg`, after which we can elide spills for this vreg (unless there is a stack use) and replace reloads with rematerializations.

```rust
trait Function {
fn can_rematerialize(&self, vreg: VReg) -> bool;
}

enum Edit {
/// The code sequence for rematerialization is only allowed to
/// use `dest` and the dedicated scratch register.
Rematerialize {
vreg: VReg,
// This is not an Allocation because rematerializing
// into a stack slot doesn't make sense.
dest: PReg,
}
}
```

## Complex rematerialization

Rematerialization involving values in other vregs is more complex and probably not worth the effort of implementing. It has been done before as part of a [research project on V8](https://csit.am/2015/proceedings/PDC/PDC5.pdf) but AFAIK this has not made it into the main V8 codebase.