RFR: leverage profiling for tableswitch/lookup switch

[Roland Westrelin]

http://cr.openjdk.java.net/~roland/shenandoah/switch-profiling/webrev.00/

This change is independent of shenandoah but the plan is to have it bake
for a bit here before it's proposed upstream. This is a follow up to:

http://mail.openjdk.java.net/pipermail/shenandoah-dev/2017-December/004535.html

1) profile collection is fixed with c1
2) C2 uses profiling to set frequencies of the branches of the switch
3) the tree of choices is trimmed down (if some branches are never taken)
4) the backend uses frequencies from profiling so scheduling is
not messed up

We saw that not having 4) messes up loop strip mining.
3) totally flies with the microbenchmarks:

before with -XX:+UseShenandoahGC:
WriteBarrierTableSwitch.common      1000  avgt   15  1109.139 ±   9.030  ns/op
WriteBarrierTableSwitch.separate    1000  avgt   15  2383.219 ± 229.815  ns/op

after with -XX:+UseShenandoahGC:
WriteBarrierTableSwitch.common      1000  avgt   15  514.100 ± 20.067  ns/op
WriteBarrierTableSwitch.separate    1000  avgt   15  505.883 ± 14.498  ns/op

I have another patch coming that should help this microbenchmark when
more than one branch of the switch is taken.

Roland.