As part of the preparation for JEP 260, Unsafe needs to be separable
from the base module, so it can be exported by a new, yet to be
defined, jdk.unsupported module, and have a separate evolution policy
that is not exposed. That is, the JDK needs an internal Unsafe that can
be evolved and added to in future releases, while maintaining the
existing Unsafe API that developers are using.

Many uses of Unsafe are for performance reasons. Any changes made
should preserve the current performance characteristics. To achieve this
the existing Unsafe intrinsic candidate methods should remain intrinsic
candidate methods. The VM can provide aliases for these intrinsics so
they are common to both the internal and sun.misc versions of Unsafe.

The JDK implementation will be updated to use the new internal version
of Unsafe.

For the purposes of making progress, this work can be split into
several phases:

1) Create the new internal Unsafe class and provide intrinsic support
    for both.
2) Update existing, and possibly add new, tests to use the new
    internal Unsafe. Some tests may need to be duplicated, or reworked,
    to test both versions of Unsafe, see JDK-8140608.
3) Update the Unsafe usages in the JDK so that there is no longer any
    dependency on sun.misc.Unsafe, see JDK-8140606.

This bug will be used for the first phase, consisting mainly of :
  - the intrinsic aliasing,
  - the new internal Unsafe ( copy of sun.misc.Unsafe ),
  - reverting sun.misc.Unsafe to, almost, its 1.8 API,
  - minimal test and implementation updates, since there some usages
    of unaligned access that is new in the 1.9.