WIP Cranelift: Avoid many small allocations in `remove_constant_phis` pass

[fitzgen]

By having a single, large allocation instead.

The motivation is that the SmallVec for each block's outgoing edges' actual argument values was often running out of their inline capacity and triggering heap allocations.

Unfortunately, this seems to ultimately be a ~3% slow down on our spidermonkey.wasm benchmark, probably due to the new bounds checks caused from indexing into the single large allocation.

compilation :: cycles :: benchmarks/spidermonkey/benchmark.wasm

  Δ = 121036165.40 ± 64555091.05 (confidence = 99%)

  main.so is 1.01x to 1.05x faster than backing-values.so!

  [3983134514 4236785350.52 4613932381] backing-values.so
  [3790337770 4115749185.12 4653228728] main.so

compilation :: cycles :: benchmarks/bz2/benchmark.wasm

  No difference in performance.

  [165139806 179373271.11 208813013] backing-values.so
  [165229705 175595715.17 202773232] main.so

compilation :: cycles :: benchmarks/pulldown-cmark/benchmark.wasm

  No difference in performance.

  [188779955 224630804.71 270825205] backing-values.so
  [189541100 222431248.35 281750519] main.so

Just opening this PR for posterity and if anyone else gets any ideas here.

[fitzgen]

Okay, I switched this PR over to using bumpalo instead of indices into a vector and got a 2-6% speed up for compilation of bz2:

compilation :: cycles :: benchmarks/bz2/benchmark.wasm

  Δ = 7290648.36 ± 4245152.07 (confidence = 99%)

  bump.so is 1.02x to 1.06x faster than main.so!

  [166388177 183238542.98 214732518] bump.so
  [172836648 190529191.34 217514271] main.so

compilation :: cycles :: benchmarks/pulldown-cmark/benchmark.wasm

  No difference in performance.

  [182220055 225793551.12 277857575] bump.so
  [193212613 227784078.61 277175335] main.so

compilation :: cycles :: benchmarks/spidermonkey/benchmark.wasm

  No difference in performance.

  [3848442474 4295214144.37 4665127241] bump.so
  [3969505457 4262415290.10 4563869974] main.so

[fitzgen]

Err, I guess github got confused by my renaming the branch of a closed PR. Going to open a new one.