RFR: 8267312: Resolve should use generated diagnostic factories

[Maurizio Cimadamore]

This patch allows Resolve to use more static diagnostic factories. Resolution errors support generation of diagnostics. This generation is very flexible and allows creating either a toplevel (error or warning) diagnostic, or a nested (fragment) diagostic. To support this, many resolution diagnostics in javac define some "overloads" in compiler.properties - e.g.


# 0: message segment
compiler.err.prob.found.req=...
# 0: message segment
compiler.misc.prob.found.req=...
# 0: message segment, 1: type, 2: type
compiler.warn.prob.found.req=...


To support switching from one diagnostic kind to another, this patch adds a new method on `DiagnosticInfo`, namely `toType(DiagnosticType)`. The default implementation of this method will simply check that the type is identical to that of the current diagnostic info, and throw otherwise.

This patch modifies the build-time step to construct diagnostic factories, so that, whenever a diagnostic overload is detected, the `toType` method is overridden, and the right constants/factories are returned/called depending on the requested diagnostic type. For instance, the factory for the `prob.found.req` key will look as follows in the generated code:


/**
         * compiler.err.prob.found.req=\
         *    incompatible types: {0}
         */
        public static Error ProbFoundReq(Fragment arg0) {
            return new Error("compiler", "prob.found.req", arg0) {
                public JCDiagnostic.DiagnosticInfo toType(JCDiagnostic.DiagnosticType kind) {
                    return switch (kind) {
                        case ERROR -> this;
                        case WARNING -> throw new AssertionError("Unsupported kind: " + kind);
                        case FRAGMENT -> Fragments.ProbFoundReq(arg0);
                        case NOTE -> throw new AssertionError("Unsupported kind: " + kind);
                    };
                }
            };
        }


As you can see, the build time process correctly detects all diagnostic overloads and generate some code to convert one diagnostic info to another. Note that in this case, only two overloads are detected (`err` and `misc`), given that `warn` has a different type comment so not, technically speaking, an overload.

With this support it is relatively easy to go back to Resolve and update most of the resolution errors to use the generated factories.

The only case I have not dealt with is the "cannot.resolve" diagnostic, which has many variants: `{ var, method, generic method } x { location, no location }`. To use the factories effectively here a change in the way the diagnostic is structured is required, but doing so, while trivial, will cause many change in the golden test files, so I held off these changes for now, and will come back later to this.

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

Commit messages:
 - Add newlines after factory method/field declaration
 - Simplify code in Resolve
 - Tweak ClassGenerator
 - Merge branch 'master' into resolve_error_diags
 - Polish properties generation code
 - Kind of works
 - Sharpen signature of compiler.properties
 - Initial cleanup; some issues:

Changes: https://git.openjdk.java.net/jdk/pull/4089/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=4089&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267312
  Stats: 248 lines in 6 files changed: 109 ins; 37 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4089.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4089/head:pull/4089

PR: https://git.openjdk.java.net/jdk/pull/4089