compiler: Fix typo in test name
compiler: DisposeValues fixes and cleanups

- Change ps.ValueDisposableStep to ps.InputDisposableStep and have it
  only dispose input values. Disposing output values can be done with
  the normal ps.Dispose and handling both input and output causes the
  codegen code to be more complex than necessary

- Rename ps.DisposeValue to ps.DisposeValues and have it take a set of
  values to dispose. This is more consistent with what
  InputDisposableStep does and can lead to less verbose plans. More
  importantly, these are much easier to unit test than individual
  dispose steps produced in an undefined order

- Switch ps.Invoke to use the ps.InputDisposableStep infrastructure and
  get rid of ps.InvokeArgument. This also lets the Invoke properly
  dispose of its entry point which doesn't affect code generation (entry
  points aren't GC managed) but is cleaner

- Fix ps.NestingStep handling to deal with the case of a branch
  returning a value produced from outside that branch. Previously that
  value would remain undisposed for the rest of the function. For GC
  managed values this meant they were effectively leaked until the
  function terminated

- Add unit tests for DisposeValues
compiler: PlanCellAllocation tweaks and cleanups

- Remove ps.CellConsumer.allocSize. All remaining cell consumers only
  consume a single cell

- When inserting AllocateCells beside a DisposeValues step always place
  the AllocateCells step after. This ensures there are fewer values to
  root during the AllocateCells GC barrier.

  There was an experiment to instead place the AllocateCells step
  immediately before the cell consumer. This produced mixed results
  while the DisposeValues change is guaranteed to always be a win.

- Clean up and adds comments to PlanCellAllocations

- Add simple unit test for PlanCellAllocation
compiler: Support for (/) planning

This supports planning of (/) with static values or dynamic values of
known types. This works similarily to how (+), (*) etc are implemented
except it always uses floating point instructions even if all the
operands are integers. This is because unlike the other arithmetic
procedures floating point values can be produced by two integer
operands.

This also adds functional tests for typed procedures wrapping (*), (-)
and (/). This ensures that their native instruction generation code
paths are exercised properly.