RFR: 8321224: ct.sym for JDK 22 contains references to internal modules

[Jan Lahoda]

As part of:
https://github.com/openjdk/jdk/pull/16505

there are new symbol files for JDK 22, and @jddarcy noted the content looks weird.

I was investigating, and found a few problems, some introduced by https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, some pre-existing.

Note that https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b changed the way we generate `ct.sym` - it now contains `.sig` files also for the current JDK, not only for the past versions. Before this patch, `ct.sym` only contained a list of permitted modules for the current JDK, and the classfiles themselves were read from `lib/modules`.

The problems (and their solution) I've attempted to tackle here:
 - since https://github.com/openjdk/jdk/commit/fc314740e947b2338ab9e4d4fce0c4f52de56c4b, the ct.sym accidentally includes all modules for the current release, including non-API/undocumented modules. The proposed solution is to pass the documented modules together with their transitive dependencies as a parameter when constructing ct.sym, then use them to only generate data for these modules.
 - there are tiny differences between the data that are in `ct.sym` and in the `.sym.txt` historical files, mostly around annotations. The `.sym.txt` files contain references to internal annotations (like `@PreviewFeature`), which are stripped or converted before the `.sig` file is written into `ct.sym`. When generating historical data for JDK N, we run `CreateSymbols` on JDK N, reading the JDK N classfiles, and producing `.sym.txt`. This is done using `--release N`, so that we read the correct span of modules. Sadly, since now `--release N` will always use the `.sig` files, we are loosing a little bit of information esp. around the annotations. The proposal here is to use `--release N` to read the list of modules to cover, and `--source N` to read the actual real classfiles from `lib/modules`. This should basically revert the behavior to the previous state.
 - this is an existing issue, but one that needs to be fixed. Sealed types are not written and read properly - writing was not storing them, and reading permitted subclasses was happening too late, not on the `header` line. Note that when fixing this, we now must store some of the non-exported elements, which are reachable through the permitted subclasses, so that casting works as expected. Also, since the historical record is incorrect here, I re-run the generator for JDK 17-21 (as sealed classes where finalized in JDK 17), changes are included here, and are the bulk of the changes of this patch.
 - when trying to find an existing class header when processing a new class header, it might have happened that an older existing version was picked up. This then caused repetition of the header in the new version. Proposed fix is to first look at the baseline existing header when searching for existing headers, and also a bit more careful computation of baseline.

As part of testing, I've written a simple program (inside tests), that prints all elements in exported packages using the `PrintingProcessor`, please see `PrintCTSymContent.java`. And printed the content for JDK 17-21 before this patch:
https://cr.openjdk.org/~jlahoda/8321224/diff.00/orig/
after this patch:
https://cr.openjdk.org/~jlahoda/8321224/diff.00/new/
and made a diff:
https://cr.openjdk.org/~jlahoda/8321224/diff.00/diff/

Looking at the diff, it seems that (as expected) it is basically addition of `sealed`&`permits` and addition of package private classes (forced by `permits`).

Symbol files generated for JDK 22 are here:
https://github.com/lahodaj/jdk/commit/06606d544cb63f007b1d4eb5196f3ca6ffd24bed#diff-0029c8ea954c5b329126d760dc307cd3235abbe4e9f0530dc301141e33746d37

There's one quirk in the current historical record files: as the `jdk/internal/foreign/` package existed in the `jdk.incubator.foreign` module, and was moved to `java.base`, the generator still puts the classes in this package into `jdk.incubator.foreign-<version>.sym.txt`. This is a quirk only in the way the `.sym.txt` files are written, when `ct.sym` is written, the `.sig` files are generated into the correct module. I may try to fix this for the future, but it does not seem to be blocker. (We need to include classes in this package due get the correct permitted subclasses handling.)

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

Commit messages:
 - Removing trailing whitespace.
 - Ensuring qualified packages are recorded properly.
 - Fixing tests.
 - Adding a way to dump the API.
 - Adding missing file.
 - 8321224: ct.sym for JDK 22 contains references to internal modules

Changes: https://git.openjdk.org/jdk/pull/16942/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16942&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321224
  Stats: 26876 lines in 194 files changed: 6106 ins; 20256 del; 514 mod
  Patch: https://git.openjdk.org/jdk/pull/16942.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16942/head:pull/16942

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