Replace ThreadLocal with a hashtable to support reliable cleanup

[WolfgangHG]

This is another attempt to work around the ThreadLocal memory leak that happens in arquillian-extension-warp. The first pull request #501 fails on Java 11 and was reverted by #579 (issue #578).

I replaced ThreadLocal with a Hashtable<Long, T> inside a utility class, where the key is the thread id. This way, it is easy to cleanup the full cache, which is done in ManagerImpl and AbstractContext.

What do you think? Is this an approach that could work? Or do I have a basic misunderstanding about ThreadLocals or did I break something else?

At least I could run the arquillian-extension-warp testsuite against a remote WildFly server ten times without OutOfMemoryException, while it failed before after 5-7 runs.

[starksm64]

Since you have demonstrated a usecase where the thread id is not a valid key for the thrown exception set, it seems like what the concurrency requirements are around this nested exception handling need to be defined. As far as I know the arquillian core is not really designed to run multiple tests in parallel, so why this was keyed on threads vs just tracking the exception class is not clear.

[WolfgangHG]

@starksm64 Is this a comment about my pull request or an overall philosophical question about arquillian ;-)? If it is philosophical, I am out - no detailed knowledge about the concepts behind arquillian...

[starksm64]

The comment was on both as it is not clear what the purpose of tracking by thread is. I can't see this causes any harm and getting rid of questionable ThreadLocal use is a good thing, so I'll merge it.