Current VMBridge is not suitable for modular JDKs

[carlosame]

VMBridge allows some customization by trying to load a org.mozilla.javascript.VMBridge_custom, however due to modularity access rules such a class would not be allowed to load in modular JDKs. Then VMBridge_jdk18 is loaded, but that class is not 100% suitable for modular JDKs (for example it handles proxy objects in a pre-modular way which could lead to failures).

As a subset of what is currently done in PR #1072, a few changes could be made to VMBridge, respecting the current API signature but changing the way that it is loaded:

1. The VMBridge_custom would be located at org.mozilla.javascript.bridge which could be provided by a different module.
2. Provide a VMBridge_jdk11 which inherits from a new VMBridge_jdk8 (keeping a VMBridge_jdk18 would be confusing) and uses the modular API.

I could modify #1072 to provide the above changes (and leave the protected access changes for a later PR).

[p-bakker]

@rbri @gbrail could you comment on whether this is still something relevant?

I tried following all the cases and (not merged) PRs related to the VMBridge, modular Java and Java 11 and could not make heads or tails out of it.

@rbri you closed your PR in this area (#1070) in favor of #1072, but neither ever got merged

@gbrail you mentioned in #1479 (comment) that we might not need a VMBridge at all now...

I'm lost... 🤔 Should we fix something, remove something, do nothing?