Peek through barriers in Node::eqv_uncast()

[Roman Kennke]

Node::eqv_uncast() seems to be used a lot in the code paths that deal
with eliminating locks, mostly to match lock nodes with their
corresponding unlock nodes, and a few other things. This seems to be a
bit fragile: if the unlock ever consumes a different input than the lock
node, e.g. because they end up with different barrier nodes on the same
object, then this will throw off lock elimination. I suspect that this
is what's happening with lucene.

I am not sure yet how lock and unlock could end up with different
barriers on same object, and I'm not actually 100% sure it fixes the
problem, therefore this RFR is preliminary to get reviews on it, and
maybe some extra testing (lucene is running fairly long, I'm midway
through my 2nd run only).

The proposed fix is:
http://cr.openjdk.java.net/~rkennke/c2-eqv/webrev.00/

Roman