compiler.batch.FileSystem.getClasspath() may return ClasspathJar for non existing classpath entry

See https://github.com/eclipse-pde/eclipse.pde/pull/236#issuecomment-1195506020
```
java.nio.file.NoSuchFileException: eclipse.pde/ui/org.eclipse.pde.core/target/ant_tasks/pde-ant.jar-classes
at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:106)
at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at java.base/sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at java.base/sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:149)
at java.base/sun.nio.fs.LinuxFileSystemProvider.readAttributes(LinuxFileSystemProvider.java:99)
at java.base/java.nio.file.Files.readAttributes(Files.java:1851)
at java.base/java.util.zip.ZipFile$Source.get(ZipFile.java:1264)
at java.base/java.util.zip.ZipFile$CleanableResource.(ZipFile.java:709)
at java.base/java.util.zip.ZipFile.(ZipFile.java:243)
at java.base/java.util.zip.ZipFile.(ZipFile.java:172)
at java.base/java.util.zip.ZipFile.(ZipFile.java:186)
at org.eclipse.jdt.internal.compiler.batch.ClasspathJar.initialize(ClasspathJar.java:201)
at org.eclipse.jdt.internal.compiler.batch.ClasspathMultiReleaseJar.initialize(ClasspathMultiReleaseJar.java:38)
at org.eclipse.jdt.internal.compiler.batch.FileSystem.(FileSystem.java:235)
at org.eclipse.jdt.internal.compiler.batch.Main.getLibraryAccess(Main.java:3495)
at org.eclipse.jdt.internal.compiler.batch.Main.performCompilation(Main.java:4741)
at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1802)
```

The code in `FileSystem.getClasspath()` may initialize a `ClasspathJar` for a classpath entry that is not existing, because after "false" returned by `File.isDirectory()` it doesn't check if the file exists at all - which is the valid case for `File.isDirectory()` API.

I have a patch, I fear however, it will break build because we most likely have the problem for a long time and most likely classpaths constructed for ECJ are not "clean", because that was silently ignored till https://github.com/eclipse-jdt/eclipse.jdt.core/pull/239.