Large Reorganization: OpenJDK, various other class files

[wasabii]

This is a biggy.

The managed-JNI classes were included in the IKVM.Runtime project under the 'openjdk' directory, shoved into a handful of files. These were very large files, containing dozens of classes each. Almost impossible to visualize and untangle.

These files are used by the static compiler to implement the IKVM specific backing of the JDK through a "simple JNI-like" interface. Java class files that declared 'native' static methods, are typically implemented by calling a JNI library. Instead if the static compiler finds a similarly named static type in the IKVM.Runtime assembly, these managed versions were called instead, without any sort of native marshalling.

In mirroring the JNI-ness of the idea, they were static classes, with no namespace, with a class name that mapped exactly to the name of the class in JNI-lingo: Java_java_lang_ClassLoader, then with static methods that implemented the actual bodies. All top-level classes, with no namespace.

Despite mapping very cleanly to JNI, this made it incredibly hard to figure out what related to what from the vantage point of a C# developer. And since we're largely free to implement this fictional JNI-like interface however we want, I decided to reorganize.

I have future plans to put these classes in an assembly outside of IKVM.Runtime, in the effort to eventually break the circular dependency. They relate specifically to the IKVM.Java assembly: the implement 'native' methods within it. They shouldn't' be treated the same as other methods inside IKVM.Runtime. They should not be called from elsewhere within IKVM.Runtime. I suspect it will eventually make sense to move them into a companion assembly to IKVM.Java named IKVM.Java.Externs (at least that's what I picked). However, as of now, there are a handful of calls from inside IKVM.Runtime directly into these classes. This should be cleaned up, but I left that as is.

They are now all split into separate files, in a hierarchy that mirrors the package hierarchy they correspond to. Frankly, this is how OpenJDK does it inside of jdk\src\windows\native and such, so I see no reason to just not do what they do. It's good organization.

Since the static compiler actually binds directly to these classes when implementing 'native' methods, this breaks existing compiled IKVM assemblies. And they'll break again when they get moved out of the assembly. But I don't think we should be worried about that for the time being. We're going through a big reorg.