Introduce a recursive/more aggressive allocation elimination pass

The hardest part for running non-local optimization passes
(i.e. the transformation does not rely only on one or a few neighboring expressions)
is to avoid re-analyse the code. Our current IR, though easy for linear scanning,
interpreting, codegen and, to a certain degree, storage, is not very easy for making random
updates. Try to workaround this issue in two ways,

1. Never resize the code array when doing updates.
   Instead, inserting nested arrays that we'll later splice back in for code addition and
   use `nothing` for code deletion. This way, the array index we cached for other metadata
   about the code can stay valid.
2. Based on the previous approach, pre-scan the use-def info for all variables before starting
   the optimization and run the optimization recursively.
   Code changes will also update this use-def data so that it's always valid for the user.
   Changes that can affect the use or def of another value will re-trigger the optimization
   so that we can take advantage of new optimization opportunities.

This optimization pass should now handle most of the control-flow insensitive optimizations.
Code patterns that are handled partially by this pass but will benefit greatly from an
control-flow sensitive version includes,

1. Split slots (based on control flow)

   This way we can completely eliminate the surprising cost due to variable name conflicts,
   even when one of the def-use is not type stable.
   (This pass currently handles the case where all the def/uses are type stable)

2. Delay allocations

   There are cases where the allocation escapes but only in some branches.
   This will be especially for error path since we cannot eliminate some `SubArray` allocation
   only because we want to maintain them for the bounds error. This is very stupid and we should
   be able to do the allocation only when we throw the error, leaving the performance critical
   non-error path allocation-free.

3. Reordering assignments

   It is in general illegal to move an assignment when the slot assigned to is not SSA.
   However, there are many case that is actually legal
   (i.e. if there's no other use or def in between) to do so. This shows up a lot in code like

   ```
   SSA = alloc
   slot = SSA
   ```

   which we currently can't optimize since the slot can't see the assignment is actually
   an allocation and not a generic black box. We should be able to merge this and eliminate the
   SSA based on control flow info. For this case, a def info that looks through SSA values
   can also help.

Author: yuyichao