Java std cleanup

[Simn]

Opening this so I don't forget. I'll go through everything again and see what else we can (re)move.

[Simn]

The String situation is a bit of a mess. The way it currently works is this:

• java.lang.String is explicitly ignored when loading the Java std.
• Any reference to it is rewritten to just String.
• In order to use the actual Java implementation from Haxe code, java.NativeString can be used.

I'd like to change it like so:

• java.lang.String is loaded like any other class.
• Any reference to it is rewritten to std.String. This ensures that we don't run into funky resolution problems.
• Referencing java.lang.String from Haxe code now finds the Java implementation, making java.NativeString obsolete.

This means that there's now a difference between referring to java.lang.String from Haxe code vs. a loaded .jar, but that shouldn't pose a problem because

1. for any Java-generated JAR we want to end up with our own String like before and
2. any Haxe-generated JAR will also write the type path out as java.lang.String.

[Simn]

Also, I'd like to do something similar for all the custom classes we currently have in std/java/lang. The abstracts there are useful for interop, but these awful custom externs for java.lang.Integer really shouldn't be a thing.

However, I'll do that in a separate PR because this one is already big enough.

[Simn]

The more I think about it the more controversial this whole java.lang.String change seems. I'll factor it out for this PR so we can look at it separately.