[MLton] an analysis to flatten refs into tuples

[Stephen Weeks]

> Looking at the diagnostics of the beginnings of the refFlatten pass,
> it looks like there will be a big win in the IO data-structures as
> well.  I see a lot of position and closed refs that look like they
> will be flattened.

Yeah, that looks promising.  Although the analysis still isn't
flattening some stuff I would like it to.  I am investigating.

Also, while writing the analysis I realized that there is a problem
that I think will require another SSA IL change to fix.  We do not
currently express selects from constructor applications; instead,
these are implicitly done by case expressions.  That was done to
simplify the IL and the type system, but is bad for a couple of
reasons.  First, it means that we have no way to move around the
conselects.  We've survived that so far (and there is a little hack in
the backend to at least remove those selects that are unused).  But
worse, we don't even have a type that refers to a single variant of a
datatype.  Hence, we can't even refer to the object so that we can
select off of it, or in the case of ref flattening, mutate the object.

The best fix I can think of is to modify the SSA IL so that we have a
new type

	ConApp of Con.t

where values of type "ConApp c" are those built by applying the
constructor c.  We can then add ConSelect and ConUpdate expressions
and can change case statements to include the (safe) downcast from the
sum type to the variant type appropriate to each branch.  Then, the
branches can do the selects and updates (safely) wherever they please.

I think I started down this road once before and backed out, because
there were problems with the simplifier needing to express the
downcast and I got tempted to introduce subtypes (where ConApp c <= t,
where t is the datatype that includes a variant for C).  But I think I
understand the issues better now and can get it right.