In preparation for planned GC performance improvements (KLUT), I would like to reduce the average number of oop map entries.

Today, when generating the object layout for an InstanceKlass, when placing non-static fields, we first lay out non-oops fields and then follow with oop fields. Given a base class with non-oop fields and oop fields and a derived class of non-OOP fields and oop fields, we get the following layout:

```
Base: non-oop fields
               oop fields
Derived: non-oop fields
               oop fields
```

Subsequently, we get two oop map entries.

A simple trick can improve this: if the super class ends with an oop, place the oops of the derived class first; otherwise, place the non-oops first.

The effect of this is that there is a higher chance for oop sections of a base class and its derived class to touch; this will cause the oop map entries for these oop sections to be fused into one, thereby reducing the number of oop map entries by one. In our example, we would see:

```
Base: non-oop fields
               oop fields
Derived: oop fields
               non-oop oop fields
```

And now we only get a single oop map entry.

Correspondingly, if the super class ends with a non-oop, we don't gain anything by leading with an oop. In that case, it is better to lead with a non-oop too and let oop fields trail the layout - future derived classes then can nestle their first oops against our trailing oops and thus use the same trick again.

If we apply this pattern consistently on every hierarchy layer of a class hierarchy, the result would be an alternation of oop-to-non-oop placement order for every hierarchy level (disregarding empty objects, etc)

This should also be safe to do since the logic is simple and predictable.