Infrastructure for immutable objects, in support of value types.

Such objects are created privately mutable, and then locked for publication.
See <http://blogs.oracle.com/jrose/entry/value_types_in_the_vm>
and <http://blogs.oracle.com/jrose/entry/larval_objects_in_the_vm>.
For more general background, see [Rich Hickey's talk on Values]
(http://www.infoq.com/presentations/Value-Values).

The term _immutable_ is a general term for certain classes of data structures.
Inside the JVM, we need a specific, positive term for an object which has been made
immutable.
We could say it has been made _final_ or _frozen_, but instead will repurpose the
term _locked_.
This is not a perfect choice, since immutability is only partially related to
synchronization.
The term allows intuitive API names like `Arrays.lockedCopyOf` or
`Objects.cloneAsLocked`.
An object which is immutable is called _permanently locked_, or (if there is no
ambiguity) simply _locked_.

Rules for permanently locked objects:

- restrictions on classes of locked objects

- all non-static fields must be final
- there must be no finalizer method (no override to `Object.finalize`)
- these restrictions apply to any superclasses as well
- an array can be marked locked, but then (of course) its elements cannot be
stored to
- if not an array, the object's class must implement the marker type
`PermanentlyLockable` (is this a good idea?)
- restricted operations on locked objects (could be enforced, or else documented as
producing undefined results)
- do not use any astore or putfield instructions, nor their reflective
equivalents, to change any field
- do not lock (you may get a hang or a LockedObjectException)
- do not test for pointer equality; use Object.equals instead (there may be a
test for this)
- do not ask for an identity hash code; use Object.hashCode instead (there may
be a test for this)
- do not call wait, notify, or notifyAll methods in Object
- at the time it is marked locked, an object's monitor must not be locked (in
fact, should never have been?)
- side effects
- elements of locked arrays are stably available to readers just like final
object fields (i.e., there is a memory fence)
- a locked object can be locked again, with no additional effect
- any attempt to mutate a permanently locked object raises
java.lang.LockedObjectException
- any attempt to synchronize on a permanently locked object raises
java.lang.LockedObjectException
- object lifecycle
- all objects are initially created in a normal (unlocked) state
- an object marked locked cannot be "unlocked" (reverted to a normal state)
- an object marked locked must be unreferenced by any other thread (can we
enforce this?)
- the reference returned from the (unsafe) marking primitive must be used for
all future accesses
- any previous references (including the one passed to the marking primitive)
must be unused
- in practice, this means you must mark an object locked immediately after
constructing it
- API
- the method `lockPermanently` is used to lock an object permanently
- there is a predicate `isLockedPermanently` which can test whether an object
is locked or not
- for initial experiments, these methods are in `sun.misc.Unsafe`; perhaps they
belong on `Object` (cf. `clone`)