RFR: Fix RichDiagnosticFormatter not to strip metadata when computing where clauses

[Maurizio Cimadamore]

The rich diagnostic formatter computes a list of "where clauses" -- that is, extra diagnostics that are meant to explain what the types in the main diagnostic are.

At some [point](https://bugs.openjdk.org/browse/JDK-8291643) it was decided to strip type annotations from the types in the diagnostics, to eliminate some noise. This created some issues:

* the logic to (pre)compute where clauses had to be adjusted to also strip metadata, otherwise discrepancies could lead to types not being found in the where clause table at the time of emitting references to them
* the preprocessing logic uses Type::toString to compare whether two where clauses types are the same -- this check is too fragile and sometimes leads to duplicated where clauses (esp. for intersection types)

In addition to these general issues, calling `stripMetadata` unconditionally in `AbstractDiagnosticFormatter`, also means that we cannot correctly render null-restricted types. While we could do something to re-add the null-restriction after stripping, this silent coupling between `AbstractDiagnosticFormatter` and pre-processing of where clauses in `RichDiagnosticFormatter` is problematic, and an obstable to improve the treatment of null-restricted types.

The solution is to avoid string-y comparison when populating where clauses. All comparison should occur either by symbol (e.g. type variables, captured types), or by `Types::isSameType` (for intersection type). Note that, since symbols are more stable, and since `isSameType` ignores metadata, we no longer need metadata stripping when computing and/or searching for where clauses.

To make the code more robust I've centralized all the logic corresponding to populating and searching where clauses inside the already-existing `WhereClauses` class. This allows the code to control how de-duplication of similarly named (but different) type-variables should occur, etc. It also leads to slightly improved client code.

This means we can now tweak `AbstractDiagnosticFormatter` to restore null-restriction after stripping. And this will now have no effect on the correctness of the rich formatter.

I've also added a separate regression test to make sure that there's only one intersection where clause generated in cases where we have two intersection types with the same component types, but different annotations. Since the annotations are stripped, this leads (before this PR) to redundant where clauses with same content.

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

Commit messages:
 - Add intersection test
 - Encapsulate code more
 - Initial push

Changes: https://git.openjdk.org/valhalla/pull/1921/files
  Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=1921&range=00
  Stats: 220 lines in 7 files changed: 133 ins; 53 del; 34 mod
  Patch: https://git.openjdk.org/valhalla/pull/1921.diff
  Fetch: git fetch https://git.openjdk.org/valhalla.git pull/1921/head:pull/1921

PR: https://git.openjdk.org/valhalla/pull/1921