RFR: 8314986: Module readability resolution is slow with large numbers of automatic modules

[Technici4n]

Fixes the issue (hopefully) by resolving automatic modules and automatic module dependencies after propagation of non-automatic transitive dependencies. The module tests run.

I also added a few asserts to validate that the automatic modules don't read themselves (previously this was the case with > 1 automatic module). Should these asserts be added in more places or is this enough?

Alan also mentioned a conflict with the spec, I'm not sure which spec is being referred to. The documentation of `ResolvedModule#reads` states `A possibly-empty unmodifiable set`, implying that the set can be empty.

Finally, `Configuration#reads` states `// The sets stored in the graph are already immutable sets` but that does not seem to be true. Should something be done about this to limit allocation?

Please let me know!
Cheers

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

Commit messages:
 - Initial automatic module perf fix

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

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