Extend IR type system for more information about pointers

Summary: Adds types like PtrToStkCell, PtrToSPropInt, etc.  This allows easy
may-alias checks on some pointers, and I think it's going to work out a lot
better than trying to push more information into the opcodes (although we're
down to 1 more Type bit unless we want to make Type bigger, which maybe we
should just do).  There are several Ld or Check opcodes we can consider getting
rid of after this.

For now this is just being used to replace the weird "canonical" source rules I
added about member instructions for frame locals---now you can just check if a
pointer could possibly alias the frame locals just based on its type.  Putting
this to more use is also going to rely on tracking down any incorrect use of
pointer types in the IR, which I'll plan on doing sometime soon.  (This diff
does fix an easy one: DefMIStateBase returned a PtrToCell, but there are
operations that can box those things while the returned tmp is still in scope.)
From some talking with@edwinsmith, it seems like the rule needs to be that if you
have a PtrToFoo, you need proof for the duration of the temp's available range
that it must always contain a subtype of Foo.  Otherwise we need PtrToGen (or
whatnot that's big enough) and guards before loading.

A couple other notes: this diff does allow creating some nonsensical types
(PtrToRefBoxedCell for example)---at first this was bothering me, but I think
it's not a big deal: our type system currently includes other impossible union
types too (e.g. Cell|VarEnv).  Also, the exact list of pointer types in the
type system is probably going to evolve (e.g. I have an Arr for now even though
it's not used for anything yet).

Reviewed By: @swtaarrs

Differential Revision: D1648913
Make emitProfiledGuard not use constrainValue on PtrToFoo types

Summary: We need to stop using constrainValue on pointer types if we want inner
types to be sound (because almost all of them will be PtrToGen).  This is an
easy one---it already knows which local or stack slot it's dealing with, and
moreover if it uses the ldLocAddr and ldStackAddr helpers it'll do the
constrain for it.  Because of preOptimizeLdLocAddr it's still going to use bad
pointer types for the locals for now, though.

This diff also makes one small behavior changes (believed to be a bug fix):
emitProfiledGuard in checkTypeStack was adding evalStack.size() instead of
evalStack.numCells(), which I think means it could guard the wrong offset, but
I think in practice we always do this when the stack has been spilled so it
doesn't happen.

Reviewed By: @alexmalyshev

Differential Revision: D1650794
Make predicted inner ref types independent of BoxedCell ssatmp types

Summary: This does part of the job of getting inner types to be factual
(PtrToFoo types isn't in this diff).  This diff adds PredictLocInner and
PredictStkInner opcodes that let frame-state track a good predicted type for
the inside of boxed values, and makes users look at those types to decide what
kind of LdRef to emit.  It also refactors minstr-translator to deal with
potentially boxed base types through this (and call simpleCollectionOp less
often---it was genning a bunch of loads just to find out types).

This diff is landable but there's more to do in follow up diffs.  I'm putting
it up as is to make sure people are ok with some not measurable, but "strictly
worse" changes in what the JIT does here:

   - checkTypeStack now always spills the stack if the type is boxed.
     Otherwise we have nowhere to track a prediction unless we add a
     PredictType opcode---after we break up spill stack this won't matter
     (because it will just change a frame state value also); and I perflabbed
     it independently and it's in the noise, so I'd rather just wait on that.

   - This removes the ability to relax guards on inner types of boxes.  I
     implemented something that does that again in another version of this
     diff: basically it treated LdRef opcodes as isGuardOps, and gives them an
     outer constraint that served the same purpose as the old inner constraint.
     But this was quite a regression (something important somewhere must not
     have been constraining the value on one of them, but I couldn't find it).
     Since this diff is in the noise without that, I'd like to just move
     forward if no one has strong objections.  (There's a fair bit of code
     relating to inner constraints that can go away with either approach here,
     but I'll do that in a follow up diff.)

Reviewed By: @swtaarrs

Differential Revision: D1656055

Signature: t1:1656055:1415215686:07c100474f89263eee9fc36d00d0674efb5406de
Remove TypeConstraint args on ldLocAddr and ldStackAddr

Summary: All callers constrain the type to specific, and they are going to
start returning PtrTo{Frame,Stk}Gen, so they don't need to be constrained.

Reviewed By: @swtaarrs

Differential Revision: D1656123
Make frame and stack pointer inner types accurate for entire SSATmp lifetimes

Summary: They were being used in a few places (mostly minstr related) to carry
flow sensitive type information from frame-state.  Convert those to get the
types either directly from frame state, getStackValue, or by carrying the type
themselves.  Now all frame and stack pointers are going to be
PtrTo{Frame,Stk}Gen, because we don't currently bother trying to get any
inferred insensitive types into them.  (We don't really have a use for that
right now either.)

Reviewed By: @swtaarrs

Differential Revision: D1659789
Remove TypeConstraint inner categories

Summary: Effectively nothing uses them after the boxed cell types diff, but
there was code trying to be able to deal with them some with pointer types that
had to go first (although it would never do anything because we were always
constraining locals and stack slots when we take their addresses).

Reviewed By: @swtaarrs

Differential Revision: D1659835
Use a small anonymous struct for the base in MinstrTranslator

Summary: Package up some info.  Suggested by bsimmers.

Reviewed By: @swtaarrs

Differential Revision: D1664599

Signature: t1:1664599:1415308659:6e5b7266050f55027aba9da100fdeb7275a5929a
Don't pretend to forward the variant argument in util/match

Summary: boost::apply_visitor only takes a non-const lvalue ref variant
argument.  By forwarding, we delay the error if you pass it a temporary until
we're creating a giant type, so it's a little better this way.

Reviewed By: @edwinsmith

Differential Revision: D1661794

Signature: t1:1661794:1415224570:654651507e88256036741f85d85823fbfab89845