RFR: 8338288: Compiler Implementation for Flexible Constructor Bodies (Third Preview)

[Maurizio Cimadamore]

This PR contains the implementation for the third iteration of the [Flexible Constructor Bodies](https://openjdk.org/jeps/492) feature.

While the feature remains largely unchanged from the previous iteration, this PR fixes some of the checks that are applied when a new inner class (whether member, local or anonymous) is constructed, either via new, or, indirectly, via super. These checks currently reside in `Resolve::resolveImplicitThis`, but this routine fails to take into account the differences between the various cases (e.g. the checks for member inner classes are different than those for local/anon classes), and this results in spurious compilation errors. Below is an attempt to describe what should happen, in the various cases.

#### Member inner classes

Whenever we see `new M()` where `M` is a member inner class, we need to lookup some `E.this` (where `E` is a class enclosing `M`), given none is provided. This same issue is also present when checking a `super(...)` constructor call: if the superclass is a member inner class `M`, then validating the constructor call implies inferring a suitable enclosing instance for `M`, as if we were checking `new M()`.

The lookup process for should look at all the enclosing instances available to us, and pick the innermost enclosing instance of type `E` such that `E` is a subclass of `M`'s enclosing class. It should be the case that  `E.this` is accessible (e.g. not in E‘s early construction context) or a compile-time error should occur.

This new check is defined in `Resolve::findSelfContaining`.

#### Local and anonymous inner classes

When creating local and anonymous inner classes defined in a `static` method, we should *not* check for the availability of an enclosing instance, as JLS 15.9.2 is silent about this (such classes have no enclosing instance). What matters, for local and anon classes defined in `static` methods, is that the class creation expression occurs in a context where we can access local variables defined in the method in which the local class is defined. This means that code like the one in the `LocalFreeVarStaticInstantiate` test is now correctly rejected.

This new check is defined in `Resolve::findLocalClassOwner`. While writing the code and looking at tests, I realized that existing diagnostics were not sufficient to capture this new condition. So I added a new one.

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

Commit messages:
 - Address review comments
 - Tweak comments
 - Tweak test and add positive test case
 - Avoid spurious errors in anon class constructor
 - Do not skip over classes in early construction context
 - Address review comment
 - Fix test summary
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/21410/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21410&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338288
  Stats: 479 lines in 19 files changed: 314 ins; 140 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/21410.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21410/head:pull/21410

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