RFR: 8184795: [MVT] non constant method handles can cause allocations in method handle combinators

[Roland Westrelin]

http://cr.openjdk.java.net/~roland/8184795/webrev.00/

This is a follow up to 8183137. test101 is an example of the problem
this change attempts to fix. test101 invokes a simple GWT combinator for
which one of the method handle targets is non constant. As a result, C2
doesn't know the type returned from that target and the change from
8183137 that should sink ValueTypePtrNodes through phi to remove the
need for allocations doesn't trigger.

This is fixed by transforming:

(Phi ValueTypePtr#1 Node#2) to (Phi ValueTypePtr#1 CheckCastPP#2)

Then pushing the CheckCastPP up through Phis until it reaches the non
constant call. The type of the return value is then known from the type
of the CheckCastPP. A ValueTypePtr can be created by adding projections
to the call for all values being returned. The oop edge is set by
allocating a new instance of the value type (that allocation is
hopefully useless and can be eliminated). The ValueTypePtr can then be
pushed down through Phis using the machinery from 8183137.

I had to disable compilation of LF as root if they return a method
handle value. The reason is that the logic in CheckCastPPNode::Ideal()
expects values to be returned in registers but is the called method is a
lambda form, I expect it could return a value as an instance. The fix
would require the logic in CheckCastPPNode::Ideal() to test if the
returned value is a class pointer or not (tagged or not).

Roland.