RFR: 8286897: Loom: Cleanup x86_64 StubGenerator

[Aleksey Shipilev]

During x86_32 porting, I ended up rewriting the copy of x86_64 StubGenerator significantly to make it more streamlined. The original x86_64 StubGenerator should enjoy the similar streamlining, since it would likely to be the template for many other architectures. 

There should be no behavior changes. The changes themselves should speak for themselves, but here is a brief list:
 - no need for `assert_asm` macros, instead do the inline checks, like the rest of Hotspot and Loom code
 - `_masm` and `masm` shadowing can just use whatever is currently defined as `__`
 - more strong cohesion between `post_call_nop`, its associated PC and its oopmap
 - consistently use `call_VM_leaf` that only takes the number of arguments, as we are doing argument pushes ourselves anyway;
 - for many moves, it is easier to use `ptr` flavors (e.g. `testq` -> `testptr`) to ease copy-pasting to other arches;
 - `generate_cont_thaw` should just do the `enabled()` check and carry the `StubCodeMark`, like other stubs do;
 - inline comments are reflowed to block-like comments, matching the usual style of stub code;
 - labels are prefixed with `L_` for clarity (used in some places in Hotspot);
 - `jfr_prolog` and `jfr_epilog` are used only once and do not carry their weight;
 - `continuation_*` are documented a bit better;

Additional testing:
 - [x] Linux x86_64 fastdebug, `java/lang/Thread/virtual`
 - [x] Linux x86_64 fastdebug, `serviceability/jvmti`
 - [x] Linux x86_64 fastdebug, `runtime/vthread`

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

Commit messages:
 - Fix

Changes: https://git.openjdk.java.net/jdk/pull/8755/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8755&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8286897
  Stats: 251 lines in 3 files changed: 103 ins; 68 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8755.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8755/head:pull/8755

PR: https://git.openjdk.java.net/jdk/pull/8755