JDK-8229959/JDK-8242888 Prototype for j.l.r.Proxy with hidden classes & class data

[Johannes Kuhn]

Now that class data support for hidden classes in master, I decided to 
tackle JDK-8229959 again.

JDK-8229959: Convert proxy class to use constant dynamic [1]
JDK-8242888: Convert dynamic proxy to hidden classes [2]

The idea is simple: Define proxies as hidden classes, pass the methods 
as class data, and access it from the Proxy with the 
MethodHandles.classDataAt() BSM.

The current prototype[3] works - and aside from one test for jshell that 
expects a stack trace element containing "jdk.proxy" as a stack trace 
element (hidden classes, duh), no new tests did fail with "make test-tier1".
Also, the aot tests fail ("link.exe not found"), if someone has some 
instructions how to get them properly run on windows, I'm very 
interested. But they are not new failures.

Problems I did run into:

I need a lookup for a class in a package to define a hidden class.
---------------------------
Solution: I inject an anchor class, obtain a lookup on it, and use that. 
The anchor is reused for the same package, and named pkg + ".$ProxyAnchor".

I need to return both the class data & created bytecode back to Proxy 
from ProxyGenerator
---------------------------
Solution: Added a record-like class that contains both bytecode as well 
as the class data.

Serialization of proxies did break.
---------------------------
Serializing the proxy descriptor was not a problem - the problem is how 
the constructor for serialization works.
It spins a MagicConstructorAccessor subclass - which requires for the 
created class to have a binary name. Hidden classes don't have one.
Solution: MethodHandles don't have this limitation, so I hacked a shared 
secret into JavaLangInvokeAccess to create such a MethodHandle,
and replaced the Reflection.generateConstructor() implementation to use 
a ConstructorAccessor that delegates to that MethodHandle.

---------------------------

In all, this is a prototype - for now, I want some feedback on the 
approach. Also a broader view - making it work is one thing.
Checking all the right boxes in all the different areas an other.
Some parts might still be a bit sloppy, but I want to know if there is 
merit if I follow the current path and polish it up.

- Johannes

PS.: I decided to use a draft PR - as with my last approaches I had 
problems when I did commit more stuff.

[1]: https://bugs.openjdk.java.net/browse/JDK-8229959
[2]: https://bugs.openjdk.java.net/browse/JDK-8242888
[3]: https://github.com/openjdk/jdk/pull/1830/files