JEP 390 introduced a 'synchronization' lint category for inappropriate uses of value-based class types in 'synchronized' expressions.

We'd like to make two enhancements to this lint category:
- Rename it 'identity' (as a more general description of what it's for)
- Produce additional warnings for inappropriate uses of 'java.lang.ref' APIs

It may make sense to support the 'identity' and 'synchronization' keys for a few releases as aliases, easing migration for anyone who has opted in to this category explicitly, or who has applied '@SuppressWarnings("synchronization")'.

Specific treatment of APIs is as follows:

1) Define a new internal annotation, @jdk.internal.RequiresIdentity, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type.

2) Apply the annotation to the following:
- The referent parameter of all constructors in classes PhantomReference, SoftReference, and WeakReference
- The obj parameter of Cleaner.register
- The type parameter T of Reference, PhantomReference, SoftReference, WeakReference, and ReferenceQueue
- The key parameter of WeakHashMap.put
- The type parameter K of WeakHashMap

3) Produce a warning whenever an expression of a value-based class type appears as an argument to one of the @RequiresIdentity method/constructor parameters above (warning due to the fact that the given API will throw once the value-based class migrates to be a value class)

4) Produce a warning whenever a value-based class type appears as a type argument for an @RequiresIdentity type parameter (warning due to the fact that the generic API will be impossible to properly use once the value-based class migrates to be a value class)

(Aside: in the future, these warnings will also be enforced for value class types. And additional JDK APIs may decide to adopt the @RequiresIdentity annotation if they also will be specified to throw on value object inputs—but we haven't identified any such APIs to date.)