hsail deopts with stack slots

[Deneau, Tom]

I have noticed that if we have a function that is big enough such that
the hsail code requires the use of stack slots, and in addition a
deoptimization point needs to save the stack slots, we currently don't
handle that case.

I think there are three things that need to happen before stack slot
deopts can work:

   1) Emit the hsail code to save the required stack slot variables
      into the hsail frame.  I think this is pretty straightfoward.

   2) Do whatever is needed to make the host trampoline code support
      stack slot variables.  Might need Gilles' help on this but I
      assume this will just mean implementing something like
      getNodeForStackSlotFromFrame or something.

   3) The oopmap data that can be used from the JVM side needs to be
      expanded to handle the case that stack slot variables could also
      be oops.

Regarding #3 above, the way the current hsail oopmap data is saved was
kind of a last minute addition and I think could use some redesign.
Currently, we know there aren't more than 16 hsail $d registers saved
at a deopt point so we have a 16-bit bitmap to cover that.  And there
was some unused space in the HsailFrame structure so we stuck the 16
bit oopmap there, actually saving it as part of the hsail deopt state
saving code.

Now we will have a possibly longer set of bits I'm assuming a better
strategy would be to not save the oopsmap at deopt time but instead
have some deopt metadata in a form that the JVM side could access
which would map a deopt "PC" to an oopmap for that PC (is this done
thru the CodeBlob for host code?).

If this strategy is better, is there already code that would produce
the oopmap metadata?  Currently, I'm not sure we even go thru the
GraalCodeInstaller for the hsail code (we hand a "merge" of the hsail
code and the host trampoline code).  Anyway, looking for advice from
those more familiar with this.

-- Tom