Use Config class loader everywhere instead of thread context classloader

JSJavaImplementationManager was using Thread.currentThread().getContextClassLoader() to define the generated class. This assumes that the contextClassLoader is somewhere in the DynJS Config's class loader chain, which is not always true.

The refactoring here exposes the Config classloader via the ExecutionContext, and migrates all usages to that.

An extension could be to make the Config only provide the parent class loader and have the Runtime build the DynamicClassLoader. This would mean the Config class is purely config.