The current support for flattening is often limited by the constraint of providing atomicity requirements when reading or updating a flat value. Most of current CPUs don't provide a way to guarantee this atomicity for any flat value bigger than 64 bits.
However, in cases where no concurrent writes can occur when a read operation is in progress, atomicity is not a concern. Strict final fields have this property. They must be initialized during the construction of the object, before the 'this' pointer can escape, and they cannot be modified once the call to the super constructor has been initiated. This particular initialization protocol for strict final fields creates two distinct phases: a first phase where the field can be updated in a strictly mono-threaded environment, and a second phase where field modification is not allowed anymore but multi-threaded read accesses are allowed.
To take advantage of this property and be able to flatten strict final fields, the JVM needs to define a new kind of layout: NULLABLE_NON_ATOMIC_FLAT. This layout doesn't aim to provide universal flattening to nullable fields of loosely consistent value, as it has been demonstrated that nullability implies atomicity. This layout is designed to be used in very particular cases where atomicity is not an issue because of additional properties of the JEP 401 model.

The NULLABLE_NON_ATOMIC_FLAT layout can also be used in another corner case: nullable empty values. When flatten, a nullable empty value consists in a single field, the null marker, which is naturally atomic. By consequence, there's no need to add atomicity requirement when handling such fields. This is currently a case where the interpreter and the JITs differ, the interpreter using a NULLABLE_ATOMIC_FLAT layout (with atomicity requirements) and JITs using special code to treat such fields as non-atomic. Using a NULLABLE_NON_ATOMIC_FLAT layout for those fields would make their handling more consistent between interpreter and JITs.

This CR covers only the runtimer+interpreter support for this new layout. JITs support will be addressed in a different CR.