By default, JVMCI and Graal initialization only occurs upon the first top-tier (i.e. tier 4) JIT compilation request. This makes sense for jargraal where the initialization is (mainly) executed by the interpreter and so noticeably contributes to VM startup costs. However, with libgraal the initialization should be sufficiently fast to not impact startup noticeably.

The motivation for making eager initialization the default for libgraal is to make Graal command line option processing happen in the same VM phase as handling of all other VM command line flags. That is, errors in Graal options should:
1. Happen deterministically, not just for apps that run long enough to trigger a top tier JIT compilation. For example: `java -XX:+UnlockExperimentalVMOptions -XX:+UseGraalJIT --version`. In a JDK build that does not include Graal, this may succeed (and print out the version info) or result in a VM error ("Cannot use JVMCI compiler: No JVMCI compiler found").
2. Stop the VM before any application code can be executed. This is just good hygiene.

It may make sense to make JVMCI initialization eager by default as well for jargraal so as to make the behavior uniform across the 2 modes.