Move compiler to a separate module

[gbrail]

It would not be difficult move the compiler -- all the stuff that generates bytecode and executes it -- to a separate Java module. We could use the ServiceLoader pattern to load it, so that there would be no configuration require other than putting it in the classpath.

We could also take this opportunity to clean up the "optimization mode" concept -- perhaps take it out and make it effectively a boolean that defaults to true if the compiler is present.

Advantages:

• Smaller code size in case that is very important to some people
• Easier for compatibility with really old systems, since the compiler now depends on JDK 9+ features
• No possibility of causing Android problems when the compiler uses packages that don't exist on Android
• Smaller packaging for Android users

Disadvantages:

• People who just include the "rhino" module and not the compiler will have worse performance, they will not know why, and they will blame Rhino.

[anonyein]

https://github.com/raphw/byte-buddy/tree/master/byte-buddy-android
There also exists generating bytecode for Android. Exclude Android maybe too early!

[rPraml]

@anonyein android is currently not excluded, but it runs only in interpreted mode.

If we move the compiler to a separate module, e.g. rhino-compiler-jdk, we can create (later) a module, e.g. rhino-compiler-android, that can generate android compatible bytecode

Disadvantages:

* People who just include the "rhino" module and not the compiler will have worse performance, they will not know why, and they will blame Rhino.

Hmm, that's a fair point. No one read the docs. 😉 Maybe we enforce, that at least/exactly one compiler module must be present. So we can make a rhino-compiler-dummy, that has to be on classpath (until we have a native android compiler)

[davidpcaldwell]

Related to #1658.