determineIfOnClasspath: getOption calls cost 78% of the all-projects scan

While testing our Eclipse based MCP server (https://github.com/vogellacompany/eclipse-mcp-server), we found lots of UI freezes in a larger workspace in`JavaModelManager.create:1028`.

`JavaModelManager.create(IFolder, ...)` scans every Java project when a folder is on no classpath (JavaModelManager.java:1026-1035). Per project, `determineIfOnClasspath` calls:

````
String sourceLevel = project.getOption(JavaCore.COMPILER_SOURCE, true);
String complianceLevel = project.getOption(JavaCore.COMPILER_COMPLIANCE, true);
````

Both are computed up front but only read inside the `isPrefixOf` branch. And they are not cheap: `getOption` reaches `hasJavaNature`, which reads the resource tree twice.

If the call is deferred to the needed case, we see a ~75-78% performance improvement off that scan.

Patch is trivial, PR to follow.

Start in JavaModelManager.java:1026-1035 and inspect determineIfOnClasspath, focusing on the getOption calls described in the issue. Verify the scan behavior with a larger workspace or the Eclipse-based MCP server context. Done means the unnecessary option lookups no longer affect the all-projects scan and the reported performance improvement is preserved.

Written by the indexing model from the issue text.