We've recently changed the recursive Java monitor mechanism
for LockingMode == LM_LIGHTWEIGHT. We could use some
stress testing.

The first test to be added is:

runtime/Monitor/TestRecursiveLocking.java

- This test has two modes:
  - 1 - outer and inner
  - 2 - alternate A and B

The SynchronizedObject class and the OUTER followed by INNER
testing model is adapted from [~aboldtch]'s test program:
runtime/lockStack/TestLockStackCapacity.java

There are a total of 18 configs for this test:
- 6 groups of the three LockingMode configs:
  - 0 - LM_MONITOR
  - 1 - LM_LEGACY
  - 2 - LM_LIGHTWEIGHT
- The first group tests recursive locking in -Xint in outer then inner mode.
- The second group tests recursive locking in -Xint in alternate A and B mode.
- The third group tests recursive locking in C1 in outer then inner mode.
- The fourth group tests recursive locking in C1 in alternate A and B mode.
- The fifth group tests recursive locking in C2 in outer then inner mode.
- The sixth group tests recursive locking in C2 in alternate A and B mode.

By default, each of the 18 testing configs runs for 5 seconds for a total
of 90 seconds of execution time with JOBS=1. Obviously higher JOBS
values will do things in parallel as resources are available. The default
version of the test is NOT run in Tier1; it is run in Tier2 intentionally since
this is a stress test.

runtime/Monitor/StressWrapper_TestRecursiveLocking_36M.java is a
wrapper that executes runtime/Monitor/TestRecursiveLocking.java for
2 minutes for each of the 18 configs for a total of 36 minutes of execution
time with JOBS=1. Again, higher JOBS values will do things in parallel as
resources are available. The StressWrapper_TestRecursiveLocking_36M.java
version of the test is run in Tier3 and is NOT run in Tier1 or Tier2.