RFR (S) 8213137: Remove static initialization of monitor/mutex instances

[David Holmes]

This impacts GC, compiler, runtime and serviceability.

Bug: https://bugs.openjdk.java.net/browse/JDK-8213137
webrev: http://cr.openjdk.java.net/~dholmes/8213137/webrev/

To facilitate changes to the Mutex/Monitor code we need to ensure there 
are no statically initialized Monitor/Mutex instances in the VM - as the 
constructors may rely on VM initialization that has not happened when 
C++ initializers execute.

There were 6 locally defined "lock" members of classes that were 
statically initialized, and these are across all areas of the VM:

  - Decoder::_shared_decoder_lock
  - DCmdFactory::_dcmdFactory_lock
  - JfrThreadSampler::_transition_block_lock
  - NMethodSweeper::_stat_lock
  - ThreadsSMRSupport::_delete_lock
  - CodeCacheUnloadingTask::_lock

The last is actually now unused and so is just deleted. The rest join 
all other Monitor/Mutex instances defined in the global list in 
MutexLocker and initialized in mutex_init(). I've verified that none of 
the monitor/mutex instances can be used prior to mutex_init, by code 
inspection - more details in the bug report.

I investigated asserting that a Monitor/Mutex is only constructed during 
mutex_init() but assertions don't fail cleanly during C++ static 
initialization - the result is that during the build jmod goes into an 
infinite loop printing out "[Too many errors, abort]".

Tested using tier1-3

Thanks,
David