ThreadPools can be poisoned by context class loaders

Newly created threads in a thread pool inherit the context class loader (CCL) of the currently running thread.
For thread pools this is very problematic because the CCL is unlikely to be reset at any point; not only can this leak another CL by accident, it can also cause class loading issues, for example when using a ServiceLoader because it relies on the CCL.

With the scala-free runtime this for example means that if an actor system threads schedules something into future thread pool of the JM then a new thread is created which uses a plugin loader as a CCL. The plugin loaders are quite restrictive and prevent the loading of 3rd-party dependencies; so if the JM schedules something into the future thread pool which requires one of these dependencies to be accessible then we're gambling as to whether this dependency can actually be loaded in the end.

Because it is difficult to ensure that we set the CCL correctly on all transitions from akka to Flink land I suggest to add a safeguard to the ExecutorThreadFactory to enforce that newly created threads are always initialized with the CL that has loaded Flink.

/cc arvid sewen