RFR: 8293020: jmod should not be treated as "small" tool for large modules

[Aleksey Shipilev]

This is similar to [JDK-8245168](https://bugs.openjdk.org/browse/JDK-8245168), but the blanket change to allow all modules be compiled with default options is a net loss. Instead, we can hand-pick the major offenders (large modules) where running jmod with normal tool options improves performance.

I instrumented the jmod to tell me the times it needs to create individual modules, and hand-picked three top modules that take multiple seconds to run.

Motivational `make clean-images images` times:


# x86_64 Server, release

# Baseline
real	0m12.040s
user	1m4.872s
sys	0m10.805s

# Patched
real	0m10.785s  ; <--- 1.2s faster
user	1m7.031s
sys	0m10.985s

# x86_64 Server, fastdebug

# Baseline
real	0m19.263s
user	2m42.317s
sys	0m18.537s

# Patched
real	0m17.911s ;  <--- 1.1s faster
user	2m52.810s
sys	0m19.092s


# x86_64 Server, slowdebug

# Baseline
real	0m44.799s
user	10m7.106s
sys	0m17.578s

# Patched
real	0m46.975s   ; <--- 2.5 sec slower
user	11m1.155s
sys	0m17.060s


I think we can accept the `slowdebug` regression in favor of improvements on `release` and `fastdebug` that most people seem to be building every day.

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

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/10062/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10062&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293020
  Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10062.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10062/head:pull/10062

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