(This was cherry-picked from master 2aa43610 for internal bug 1952616.)

The VM has some timeouts that are meant to kill the current process if
something gets stuck (e.g. a thread grabs a lock and then manages to die
while the rest of the process continues on).  These were tripping a
little too easily during some high-load situations.

This changes the order of operations so that we now unlock the "thread
suspend" lock before sending a wakeup broadcast to the condition variable
that threads sleep on.  This should make it less likely for a thread to
be running for an extended period while the lock is held.  (Relates to
internal bug 1664687.)

This also wraps a couple of things (pthread_create, dlopen) with a state
change to VMWAIT.  During high load situations these can take a while to
complete, and we would (with the K-Means Visualizer load generator
running) very occasionally time out.

Augmented the debug output in a couple of minor ways.  Updated comments.

Switch from VMWAIT to RUNNING when executing code on behalf of the
debugger.  Reset the thread-suspend lock timeout if we have to suspend
while trying to acquire it.

Also, clear any pending exception before calling interpreted code.

Reworked some log messages to make them easier to decipher.

(For internal bug 1952616.)

if the priority is logically-lower than ANDROID_PRIORITY_BACKGROUND

Signed-off-by: San Mehat <san@google.com>

Since we're executing interpreted code it's best if we set the context
class loader as late as possible in this function.  I also updated a few
comments while I was in there.

Also temporarily bumps the scheduler group for background threads while performing GC

Signed-off-by: San Mehat <san@google.com>