[code-reflection] RFR: Lump constructor reference with method reference

[Maurizio Cimadamore]

This PR merges constructor and method references together. The two share several commonalities -- they both have an owner type a name and a function type. The only distinction is that a constructor reference always has the special name `<init>` but that can be easily accommodated.

When merging, most of the effort went into the resolution routines. `MethodRef` provided two families of resolution methods:

1. `resolveToDirectMethod`, `resolveToDirectHandle`
2. `resolveToMethod`, `resolveToHandle`

The methods in (1) seemed to look for a _declared_ method in the reference's owner type. E.g. for a reference like `A::m()`, the methods in (1) threw an exception if the resolved method/handle pointed to a method that was not in `A`.

The methods in (2) looked for any (accessible) matching method. So, in the above case, if the result of resolution was some `B::m()` that would be returned instead.

In other words, (1) is used when treating the method reference as a _declaration_, whereas (2) is used when treating the method reference as a use site, or call site.

Perhaps unsurprisingly, some of these combinations were never used: `resolveToDirectHandle` doesn't make much sense -- typically a method handle is needed to perform an invocation, in which case you probably want same semantics as a bytecode `invokeXYZ` instruction. Similary, `resolveToMethod` was never used -- because, when looking for a declaration, it's likely one doesn't want to appeal to inheritance.

For these reasons I decided to only include the resolution methods that were actually used, and refine the naming scheme a little:

1, `resolveToDeclaredMethod`, `resolveToDeclaredConstructor`
2. `resolveToHandle`

To keep the naming consistent, I also updated `FieldRef::resolveToMember` to `FieldRef::resolveToField`. Notably, `FieldRef` didn't provide "redundant" resolution methods.

I also tightened the impl of the methods in (1) so that they no longer require an `InvokeKind` parameter -- since these methods just look at declarations using core reflection, we don't need an invocation kind (which is needed when resolving to a method handle).

I also added javadoc to both `MethodRef` and `FieldRef`, to capture the indend semantics.

All copiler and JDK tests pass. All examples in `cr-examples` build and pass tests (I had to tweak the pom file for the triton example, as that seemed broken).

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

Commit messages:
 - Revert spurious test changes
 - Fix trivial issue in validation
 - Add javadoc
 - Cleanup resolution method names
 - Simplify resolution of MethodRef
 - Initial push

Changes: https://git.openjdk.org/babylon/pull/677/files
  Webrev: https://webrevs.openjdk.org/?repo=babylon&pr=677&range=00
  Stats: 606 lines in 24 files changed: 278 ins; 233 del; 95 mod
  Patch: https://git.openjdk.org/babylon/pull/677.diff
  Fetch: git fetch https://git.openjdk.org/babylon.git pull/677/head:pull/677

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