Backport r12696: TRUENAME for URL-PATHNAME ambigiously either a directory or file now (mostly) normalizes to the directory.
If there is no type, query or fragment in a URL-PATHNAME passed to
TRUENAME, it contains a NAME compoment, there is a resource accessible
(via java.net.URL.openConnection()), and there is a resource similarly
accessible via appending a "/" to the namestring, we return a pathname
that refers to the latter resource.
We do this to overcome the bug that autoloading ABCL from a *LISP-HOME*
that is a URL-PATHNAME fails for calls such as
(autoload 'jclass-fields "java")
as Load.findLoadableFile() returns a pathname for which java.net.URL
actually opens "<*LISP-HOME*>/java/". There is no way from the
java.net.URL implementation to determine that this is a directory
without reading from the stream. The more correct solution would be
to program a restart which if the load fails it would retry with
another possible URL, but we hope that this heuristic will cover the
vast majority of usage as providers of URL references used as a
filesystem usually avoid such ambiguous references.