Scalar Replacement

[dubiousconst282]

While this pass would ideally be applied before SSA promotion, that would likely significantly reduce candidates because inlining only happens after it, and we can only mark an allocation as non-escaping if all their uses are from field accesses.

TODOs:

• Support for simple newobj constructor + field accesses
• Support for structs
  • Depends on #19
  • Or does it? Seems like it would be pretty trivial to split struct variables into scalars, as long as they aren't fully exposed / accessed.
• Rebuild SSA for promoted scalars
  • Currently we reapply the SsaPromotion pass when the SROA yields changes. It might be possible to use the Simple and Efficient SSA construction algorithm for a more efficient incremental approach.
• More efficient support for recursive objects
  • Currently doing iterative passes. Could probably use a worklist-based algorithm instead?

Bugs:

• Ensure scalars are zero initialized
  • a8088d8 introduced promotion for fields with a single-store, in some cases it will generate non-strict SSA, which is technically bad but should mostly work assuming localsinit is true.