This is an attempt at refactoring the BiVariableMap interface so it no longer keeps a copy of every single Ruby variable. It does still have to store all local variables, but for everything else it can retrieve them from either the specified receiver object or the Ruby runtime's global state.

This means instance varibles are no longer stored in BiVariableMap, thus they can no longer cause the #8527 memory leak. It should also improve performance somewhat because it avoids a lot of copying before and after every evaluation.

It does however introduce 2 minor behavior changes:

• Since the "java type" of variables set via the RedBridge API can also no longer be stored, it is no longer preserved across the set/evaluate/get cycle. That is, a variable that has been set to a String[] will now come back as a RubyArray object (which can be used as a List<String>, but not String[]) when retrieved after evaluation. This is undocumented behavior, but it's a change from the previous behavior where reading the variable after evaluation would always try to convert its value back to the same type that was used for setting it.
• Variables are no longer snapshotted after evaluation. For LocalContextProviders that use the global runtime, i.e. ConcurrentLocalContextProvider and obviously SingletonLocalContextProvider, this means that other threads can change the value of a global variable, constant, class variable, etc. between the evaluation and when the variable is read. As far as I can tell, evaluation and retrieval of (global etc.) variables has never been an atomic operation to begin with, but the timing window for getting race-y behavior is now somewhat larger.