remove thread from thread group on termination

In the OpenJDK library, ThreadGroup maintains an array of all Threads
in that group, so the VM must explicitly remove threads as they exit
or else neither they nor any objects they reference will be eligable
for GC.
avoid allocating a new gen2 heap larger than the available heap capacity
fix System.loadLibrary for OpenJDK tails=true build
fix unintentionally retained finalizables and improve low mem performance

Objects which are eligable for finalization must be retained until
after their finalize methods are called.  However, the VM must
determine the entire set of such objects before retaining any of them;
otherwise the process of retaining a given object may cause others to
become reachable and thus be considered ineligible for finalization
even though they are only reachable via other finalizable objects.
The end result of this mistake is that only a few of the objects which
are finalizable will be recognized at each GC cycle, so it requires
many such cycles to find them all, and if new objects become
finalizable at a faster rate, the VM will never catch up and
eventually run out of memory.

This patch fixes the above mistake and also includes tuning to
minimize the need for GC in low memory situations.
add avian.trace.port property

Setting this property (e.g. -Davian.trace.port=5555) will cause the VM
to start an extra daemon thread which listens on the specified TCP
port for incoming connections and dumps stack traces for all running
threads to that socket.  You can retrieve that dump using e.g. netcat:

  nc localhost 5555
briefly enter idle state in get*Volatile

In order for a thread to enter the "exclusive" state such that no
other threads are active in the VM, it must wait for all active
threads to enter the "idle" state.  In order for this to happen in a
timely manner, threads must check frequently to see if a thread is
waiting to enter the exclusive state.  These checks happen at every
memory allocation, wait, sleep, native call, etc.  However, if a
thread is in a busy loop that does none of those things, it will block
any other thread from entering that state.

The proper way to address this is to detect such loops (or tail
recursion in tail-call-optimized builds) at compile or interpret time
and insert explicit checks.  This hasn't been a high priority thus
far, though, since we had yet to encounter such code in the wild.

Now, however, we find that scala.concurrent.forkjoin.ForkJoinPool.scan
(and possibly some versions of java.util.concurrent.ForkJoinPool.scan,
on which we assume the former is based) has just such a loop.
Fortunately, that loop calls Unsafe.getObjectVolatile, which the VM
implements and thus can treat as a checkpoint.  That's the workaround
we use in this patch.
first step towards supporting Android class library on Windows

A majority of the tests are passing, but more work is needed to get
them all to pass.