Replace addScriptRuntimeInvoke("string-literal") with method info computed at runtime

[ZZZank]

The intention of this PR is the same as #1948 : to make code gen works even after a package renaming (aka relocating)

In order to handle such a large amount of method references to ScriptRuntime, a new enum class ScriptRuntimeMethodSig is introduced, with each enum value holding code gen related information for a method in ScriptRuntime.

See javadoc for ScriptRuntimeMethodSig for more info: link

In theory this PR is completed and ready for review, but I dont know how to suppress the "ImmutableEnum" error when doing gradle check, so draft for now

[gbrail]

I haven't had a chance to read this yet, but you can check here for the warning:

https://errorprone.info/bugpattern/[ImmutableEnumChecker](https://errorprone.info/bugpattern/ImmutableEnumChecker)

[rPraml]

This is really cool. But please take a look if this will work when method with different signatures are here as in this PR https://github.com/mozilla/rhino/pull/1957/files

[ZZZank]

But please take a look if this will work when method with different signatures

Yes it will work. Take memberRef as an example:

rhino/rhino/src/main/java/org/mozilla/javascript/optimizer/ScriptRuntimeMethodSig.java

Lines 50 to 53 in e9e5255

	memberRef_member,
	memberRef_namespaceMember,
	memberRef_name,
	memberRef_namespaceName,

There're 4 memberRef methods with the same name but different signatures in ScriptRuntime, and they are linked to 4 enum values presented above.

[rPraml]

This init code is really "java-magic"

• the ScriptRuntime-class needs the MethodSig-enum in annotations
• the static initialzer of the MethodSig-enum needs the annotations in ScriptRuntime.

First I thought, that this will not work, because we have a cycle (but somehow the JVM can handle this and probably in some JLS the behavior is described exactly)
if we are sure, that this will work on all VMs etc, all good
...otherwise I would suggest to move the init code to the BodyCodeGen

[ZZZank]

I briefly walked through JLS for enum class, and unfortunately there doesn't seem to be a behavior definition for what we're doing here. But I do found out that:

enum SomeEnumClass {
    static {
        SomeEnumClass.values();
    }
}

is valid, which indicates that enum members are already initialized when doing class static initialization, so what we're doing here should be fine

[gbrail]

This is a clever solution, barring @rbri 's comments about static initialization order.

Is it your intention to see this through to the end? The bootstrap method for INDY instructions, and everything in OptRuntime, for example, still aren't replaced using this mechanism.

[ZZZank]

Is it your intention to see this through to the end?

My plan is to, at least, replace all method references in BodyCodeGen, so that even if I dont have much time for it, other volunteers can know how this works and continue working on it. I will certainly see this through to the end, if time permitted