[search] Inconstistent mix of source vs binary from JDK

I don't (yet) have a plain JDT reproducer, but from work on Object Teams I observed that search my cause problematic combinations of source and binary types from the same JDK module.

When search finds a possible match in any JDK class, it will ask the SourceMapper to provide the corresponding source, inside of which the match should be located.

The source will undergo complete processing by the compiler (up-to resolve). During this process additional JDK classes will need to be loaded, at which point `org.eclipse.jdt.internal.core.builder.ClasspathJrtWithReleaseOption.findClass()` will be used.

If the requested release is found in `ct.sym` then all types will be answered from there.

Note, however, that `ct.sym` contains public types only. The source code of an arbitrary JDK class may, however and of course, reference internal classes.

As a result, perfectly legal code will encounter `{0} cannot be resolved to a type` errors.

Unfortunately, such errors may escalate when the same missing type is also referenced from a binary type, causing `AbortCompilation` to be thrown (via `ProblemReporter.isClassPathCorrect()`).

Next in the chain of events, `MatchLocator.locateMatches()` will catch the exception and remember this as `bindingsWereCreated = false`.

From here on, `MatchLocator` gives up with exact matching (assuming the classpath is broken and no decent resolving can be done anyway).

As a result, a search that was initially restricted to exact matches all the sudden answers tons of inexact matches (since exactness cannot be determined without resolving).

I can reliably reproduce the problem in the Object Teams fork when running `JavaSearchBugs16Tests.testAIOOBEForRecordClassGh790()`. I could furthermore identify the reason why what happens in the Object Teams fork does not happen in JDT with the same input: it's a simple and innocent sorting of `possibleMatches` before those are processed. This indicates that JDT is only lucky to use a 'happy' order of possibleMatches to avoid the above hassle.