RFR: 8344802: Crash in StubRoutines::verify_mxcsr with -XX:+EnableX86ECoreOpts and -Xcheck:jni

[Volodymyr Paprotski]

@TobiHartmann  There are still some unanswered questions I have, but committing this since we need to work around vacation schedules.

**This in fact happens on both Windows _AND_ Linux.** However, _only_ on Windows there is a crash. This fix fixes the crash but I don't understand entirely why the crash happens in the first place.

The issue fixed here are all the CheckJNI warnings:

OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall


Crash has nothing to do with String.indexOf work, but was introduced by my `8319429: Resetting MXCSR flags degrades ecore` change. I was able to get HelloWorld to crash on Windows (`-Xcheck:jni -XX:+EnableX86ECoreOpts`). Same command on linux produces hundreds of CheckJNI warnings. Is it odd that its only being found now, no other CheckJNI tests?

I would appreciate some help/reviews from somebody more aware of the Java-to-C linkage. I think I got the masks fixed, but there is one specific place (see the 'FIXME' question in the diff) for Windows I am not certain about. (@sviswa7 is on vacation for few more weeks)

Note: Crash on windows (if I have the Windows debugger actually correct), happens on:

0x000001f2525f13c1:   fxrstor64 (%rsp)
Stack:
0x00000088f1bfe060:   00007ff8b4384310 0000025bfaeb2200


`00007ff8` _seems_ like a valid mxcsr value, only way it should crash is if top 2 bytes weren't zeroes, which they are.

-------------

Commit messages:
 - whitespace
 - fix mxcsr JNI checks

Changes: https://git.openjdk.org/jdk/pull/22673/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22673&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344802
  Stats: 42 lines in 8 files changed: 15 ins; 19 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22673.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22673/head:pull/22673

PR: https://git.openjdk.org/jdk/pull/22673