[code-reflection] RFR: Regularize support for Java types/references [v3]

[Maurizio Cimadamore]

> This PR regularizes the support for Java types in the code model. There are two competing constraints to balance: on the one hand, the Java types should be readable from humans when inspecting the textual form of code model; on the other hand, we don't want to bake in Java-specific type parsing in the core code model API.
> 
> Unfortunately, the current implementation scores poorly on both aspects, as (a) textual Java types can become very hard to read (e.g. `.<.<NewTest, NewTest$B>, NewTest$B$C>`), and (b) the parsing logic (defined in `DescParser`) contains several ad-hoc extensions that are only there to support Java types.
> 
> To address this, this PR introduces two different kinds of externalized type forms: *inflated* type forms and *flattened* type forms. An inflated type form closely follow the structure of the `JavaType` or `JavaRef` it models. For instance, the Java type `Foo<? extends Bar>` is modelled as follows:
> 
> 
> java.type.class(Foo, java.type.primitive(void),
>                   java.type.wildcard(EXTENDS,
>                                      java.type.class(Bar, java.type.primitive(void))))
> 
> 
> Inflated type forms can be *flattened* (using `JavaTypeUtils::flatten`), to derive a form that is more suitable for humans. For instance, the above inflated form is flattened as follows:
> 
> 
> java.type:"Foo<? extends Bar>"
> 
> Conversely,  flattened type forms can be *inflated* back (using `JavaTypeUtils::inflate`) to their original inflated form.
> 
> This distinction between inflated and flattened forms allow us to massively simplify `DescParser` -- which no longer has to worries about the syntactic vagaries of Java types. All that complexity is now pushed onto the flattened type forms support. The goal is to progressively make flattened Java type forms an "implementation detail" (more on that below).
> 
> To accommodate flattened and inflated type forms, two changes are needed:
> * in `OpWriter` we need to flatten an inflated type form (if possible) before writing it out as a string (this allows for the textual form of a code model to be more readable)
> * in `OpParser` we need to inflate a flattened type form (if possible) before handing the type form back to the rest of the parsing machinery (which will e.g. invoke the type factory on such inflated type form)
> 
> All Java types and references now follow this pattern:
> 1. the `externalize` method returns an inflated type form
> 2. the `toString` method returns a readable string (the one associated with the corresponding flat type ...

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:

 - Enhance type factory to create refs
 - Merge branch 'code-reflection' into externalized_Java_type_cleanup
 - Simplify parser code to use `Lexer::is`
 - Fix JavaType grammar
 - Drop redundant field
 - Add Javadoc to `JavaTypeUtils`
 - Cleanup exType parser
 - Cleanup and strengthen code that tests for the specific kind of externalized type
 - Remove parens from method type var external type strings
 - All tests pass
 - ... and 9 more: https://git.openjdk.org/babylon/compare/d1e22c58...067d4371

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

Changes:
  - all: https://git.openjdk.org/babylon/pull/432/files
  - new: https://git.openjdk.org/babylon/pull/432/files/cf48f74c..067d4371

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=babylon&pr=432&range=02
 - incr: https://webrevs.openjdk.org/?repo=babylon&pr=432&range=01-02

  Stats: 8122 lines in 58 files changed: 5141 ins; 2683 del; 298 mod
  Patch: https://git.openjdk.org/babylon/pull/432.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/432/head:pull/432

PR: https://git.openjdk.org/babylon/pull/432