Classloader isolation not tight enough for libraries that spawn threads

The framework now has pretty much all entry points to components covered via a nice NarCloseable construct. However, it is always being set to use the NarThreadContextClassLoader as the set context class loader. This is good in that it means the specific Nar class loader will be found for classes created by those threads since they remain in the call stack and the NarThreadContextClassLoader can then rehome them to their nar. This is bad though when those libraries spawn threads before we ever end up changing the classloader to the nar specific classloader as those threads will have nothing in their callstack that leads them back to the specific nar.

This was found while testing parallel usage of the Kafka 0.9 and Kafka 0.10 client processors. I could run one of them at a time but not another. In Kafka's code it is clear where they try to properly use the context class loader. So in debugging found that we were in their thread but still not jailed to the proper Nar specific class loader which means game over as their call stacks won't hit. Therefore, rather than setting everything to the generic 'find it later' classloader we should instead use this NarCloseable construct but have it directly jailed to the NarClassLoader of the component in question.

This is likely to be addressed in the commits for NIFI-2608/PR-930.