Re-examine when JNI methods should be allowed during the VM initialization process

JDK-8308341 exposed an issue where by JNI_GetCreatedJavaVMs could return a partially initialized VM for which JNI_AttachCurrentThread could crash. That fix initially added checks to the attach/detach functions to make them fail if the VM was not completely initialized. But that was too strong a check as we discovered (JDK-8309171) that a native agent could create native threads that have to attach during VM initialization. It was suggested that the latter problem should still be restricted to the JVMTI "live phase" but it is unclear if that necessarily suffices - a JDK library could also create a native thread that tries to attach to the VM (though we could of course declare that a bug and force it to be delayed).

In any case we should look at whether the JNI-related VM initialization states (NOT_CREATED, IN_PROGRESS, COMPLETED) should be expanded to give more fine grain control that can be used to guard use of other JNI functions like attach/detach.

It was also suggested that we might consider blocking such functions if VM init is in progress rather than returning an error. Though I suspect that could lead to initialization deadlocks.