Should the Java editor & hover pay any respect to the --release option

Spawned off from https://github.com/eclipse-jdt/eclipse.jdt.core/issues/3168 :

When a project is configured with --release that differs from the actual JDK used, then the IDE runs into the following schizophrenia:
* some parts of the tooling will see JDK classes as they were in the version configured using --release
* currently, the --release version is used only in actual compilation, but the goal in jdt.core would be to use that version consistently for all "semantic" operations, including reconciler, search etc.
* source attachment and javadoc location will however correspond to the actual JDK

As a result, users may get an error like "The method of(null, null) is undefined for the type URL" in their source code, but when they navigate to class URL (which uses the source attachment) that method may actually be there.

This ticket is filed to stipulate discussion, if there is a viable way to "explain" this situation to the user.

Here's a somewhat advanced idea: when opening a JDK class in an editor, jdt.core could be asked if that class has any difference between the --release version and the actual JDK version. If so, somehow signal to the user: "This class has changes between the currently shown version and the version configured using --release" or similar.

Similarly for javadoc hovers.

Start with the linked jdt.core issue 3168 and trace how --release is used for compilation, semantic operations, source attachment, and Javadoc hovers. Assess whether the Java editor can detect differences between the configured release and actual JDK, and define a user-facing signal for editor and hover views. Done means the proposed behavior and scope are resolved consistently.

Written by the indexing model from the issue text.