RFR (S) 8216302: StackTraceElement::fill_in can use cached Class.name

[Aleksey Shipilev]

RFE:
  https://bugs.openjdk.java.net/browse/JDK-8216302

Fix:
  http://cr.openjdk.java.net/~shade/8216302/webrev.01/

There is already Class.name field that is used as the cache for Class.getName(). We can use that
from inside the VM code when building the stack traces, to avoid converting Symbol*->String all the
time. We have to take care that both Java (JVM_GetClassName) and internal paths yield the same
cached value, so some code rearrangement and tests are in order.

This alleviates a part of stack trace performance degradation that happened 8->11, see the umbrella
issue for test and discussion:
  https://bugs.openjdk.java.net/browse/JDK-8151751

Linux x86_64 release:

# 8u191
StackTraceBench.test        1  avgt   15    10.851 ± 0.075  us/op
StackTraceBench.test       10  avgt   15    15.325 ± 0.089  us/op
StackTraceBench.test      100  avgt   15    59.717 ± 0.449  us/op
StackTraceBench.test     1000  avgt   15   529.020 ± 3.654  us/op

# jdk/jdk, baseline
StackTraceBench.test        1  avgt   15    23.835 ± 0.188  us/op
StackTraceBench.test       10  avgt   15    33.204 ± 0.191  us/op
StackTraceBench.test      100  avgt   15   125.195 ± 0.694  us/op
StackTraceBench.test     1000  avgt   15  1051.047 ± 9.779  us/op

# jdk/jdk, patched
StackTraceBench.test        1  avgt   15    14.450 ± 0.136  us/op
StackTraceBench.test       10  avgt   15    20.182 ± 0.088  us/op
StackTraceBench.test      100  avgt   15    77.107 ± 0.632  us/op
StackTraceBench.test     1000  avgt   15   647.128 ± 6.159  us/op

Testing: Linux x86_64 fastdebug {new test, hotspot tier1}, jdk-submit (running)

Thanks,
-Aleksey