In HotSpot we sometimes introduce features under -XX flags that we would like to consider experimental for some time before officially supporting them (once we are satisfied of their reliability). However, we do not have a clear way to tell our users which options to consider as experimental.

This CR proposes the introduction of a new flag -XX:+UnlockExperimentalVMOptions. Only when this flag is set, options deemed experimental will actually be allowed to be set. Such options will be tagged in globals.hpp with experimental(...), in the same way that today they are tagged with product(...) and/or debug(...). It basically follows the way diagnostic options are tagged, with diagnostic(...), and unlocked, with -XX:+UnlockDiagnosticVMOptions.

There are several advantages to this approach.

- It will be a warning to the customers that the options they are using are considered experimental.
- Upon a customer complaint, it will allows us to quickly grep through their cmd line options to find out whether they were using an option they were not supposed to (without having to work out whether option XXX was considered experimental in release YYY).
- It will make it easier to introduce half-baked work in the VM, given the more aggressive release schedule through HotSpot Express.

First VM options that we are planning to add under the experimental blanket is -XX:+UseG1GC.