C2: x86_64 Java_To_Runtime calls should be direct

There is the indirection to call form Java to runtime:

x86_64.ad:

  enc_class Java_To_Runtime(method meth) %{
    // No relocation needed
    MacroAssembler _masm(&cbuf);
    __ mov64(r10, (int64_t) $meth$$method);
    __ call(r10);
  %}

...which ends up taking quite a bit of space (13 bytes):

  0x00007fd2884362a8: movabs $0x7fd2a010c520,%r10
  0x00007fd2884362b2: callq *%r10 ;*invokestatic nanoTime
  0x00007fd2884362b5: ...

If we avoid that indirection, by calling to literal with proper reloc type (runtime call), then we take only 5 bytes:

  0x00007f5d84434ac8: callq 0x00007f5d9c5aa5b0 ; invokestatic nanoTime
  0x00007f5d84434acd: ...

So it improves code density.

This also enables better annotation in generated code. For example, Shenandoah barriers slowpath calls (emitted with CallLeaf) currently show up like this:

  0x00007faf7c4333ed: mov %rax,%rdi
  0x00007faf7c4333f0: movabs $0x7faf94b72fd0,%r10
  0x00007faf7c4333fa: callq *%r10

...and with the patch above, decoder finally grasps what that literal is pointing to:

  0x00007f5d8442f7e5: mov %rax,%rdi
  0x00007f5d8442f7e8: callq 0x00007f5d9c739060 ; {runtime_call ShenandoahRuntime::load_reference_barrier_narrow(oopDesc*, unsigned int*)}

Proof-of-concept patch:
  https://cr.openjdk.java.net/~shade/8244521/webrev.01/

Major caveat: there is actually no guarantee runtime call is near so we can do rip-based encoding. The size estimate needs to be adjusted for those cases...