RFR: 8273831: PrintServiceLookup spawns 2 threads in the current classloader, getting orphaned

[Sergey Bylokhov]

The PrintServiceLookupProvider can spawn 2 threads on WIndows and one thread on Linux. These threads are connected to the classloader of the web application.  During undeployment the app classloader gets removed together with the two orphaned threads by the Tomcat. 

Looks like the tomcat has special machinery to workaround such threads:
https://cwiki.apache.org/confluence/display/tomcat/MemoryLeakProtection#MemoryLeakProtection-cclThreadSpawnedByJRE
But it should be updated each time we add/update/rename the threads in the JDK. So JreMemoryLeakPreventionListener can be updated to solve this problem, but it will be good to reset the ref to the app class loader as we usually do for our internal threads. 

The change updates threads to use the root thread group and null context class loader.

A similar pattern is used here:
https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.desktop/share/classes/com/sun/imageio/stream/StreamCloser.java#L89

@aivanov-jdk please take a look

-------------

Commit messages:
 - cleanup
 - Update PrintServiceLookupProvider.java
 - Update FlushCustomClassLoader.java
 - cleanup and test
 - Update PrintServiceLookupProvider.java

Changes: https://git.openjdk.java.net/jdk/pull/5939/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5939&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8273831
  Stats: 120 lines in 3 files changed: 104 ins; 3 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5939.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5939/head:pull/5939

PR: https://git.openjdk.java.net/jdk/pull/5939