use separate VMStructs databases for SA and JVMCI

Currently JDK-8062493 uses the existing VMStructs database which the SA also uses. In order to be more flexible with the future of the SA the JVMCI should use it's own database.

Some thoughts for a possible solution:

 - Add fields to the CompilerToVM class (or a separate class) which holds immutable values that are read via public API methods of other classes.
 - For mutable data values we add native VM entry points to retrieve them.
 - Constant values (like enums) are still read from the actual classes via VMStructs (there are too many and it doesn’t make sense to duplicate constants).
 - Most field offsets are used to read immutable data (e.g. Method flags). We need to discuss how we are going to handle these.
 - Some field offsets are needed to be encoded in compiled code. At this point I don’t know how many these are but if the number is reasonably low we could store them in the CompilerToVM class too.
 - A separate JVMCI VMStructs database will contain the fields of CompilerToVM and constants of other classes (this enables the removal of the VMStructs database of the SA).