RFR: 8203948: Expand JVMTI callback notion of "internal threads"

[Kim Barrett]

Please review this change to JVMTI to relax some restrictions on where
some functions may be called.  Presently they are restricted to being
called from either a Java thread, the VM thread, or a thread for which
is_ConcurrentGC_thread() returns true (e.g. ConcurrentGCThreads and
AbstractGangWorkers (if the containing WorkGang is configured as
concurrent).

We now allow these functions to be called for either a Java thread or
a Named thread, e.g. any of the VM thread, ConcurrentGCThreads, or
WorkerThreads.  This allows the restricted functions to be called from
any WorkerThreads, rather than only AbstractGangWorkers in concurrent
WorkGangs.

The change to jvmtiEnter.xsl affects the following generated
functions:
jvmti_Allocate
jvmti_Deallocate
jvmti_CreateRawMonitor
jvmti_DestroyRawMonitor
jvmti_RawMonitorEnter
jvmti_RawMonitorExit
jvmti_RawMonitorWait
jvmti_RawMonitorNotify
jvmti_RawMonitorNotifyAll
jvmti_GetTimerInfo
jvmti_GetTime
jvmti_SetEnvironmentLocalStorage
jvmti_GetEnvironmentLocalStorage

CR:
https://bugs.openjdk.java.net/browse/JDK-8203948

Webrev:
http://cr.openjdk.java.net/~kbarrett/8203948/open.00/

Testing:
Mach5 tier{1,2,3} and hs-tier{4,5}

There are no tests that directly exercise the relaxed restrictions
yet.  We'll start hitting that as part of in-progress work to
parallelize WeakProcessor, which calls JvmtiExport::weak_oops_do,
which generates ObjectFree events, which uses the Raw Monitor API.