Fix FileDownloadUtils validation and implement checksum verification - #1133

The download-validation helpers added in 7.0.0 (biojava#979, biojava#980) had several gaps
that only surface once a caller passes a real hash URL or downloads from a
server that can 404. All of them are fixed here, and hash verification is
implemented rather than stubbed.

Correctness fixes:

* createValidationFiles(URL, ...) passed a literal Hash.UNKNOWN to its
  URLConnection overload instead of the caller's argument, so it could never
  write a hash file and threw IllegalArgumentException for any caller that
  supplied a hashURL.
* Neither downloadFile nor createValidationFiles checked the HTTP status, so a
  404 error page was written into the cache as though it were the requested
  file. Because the .size sidecar was then taken from that same error response,
  validateFile subsequently declared it valid. A new HttpStatusException lets
  callers tell "the resource is not there" apart from a transport failure,
  which matters for anything that tries several mirrors in turn.
* downloadFile used FileChannel.transferFrom(rbc, 0, Long.MAX_VALUE), which is
  not guaranteed to drain a socket-backed channel and could silently truncate a
  download. Replaced with Files.copy, which loops to end of stream.
* downloadFile leaked its temporary file on every failure path.
* validateFile threw NullPointerException for a file with no parent directory,
  and again if listFiles() returned null; an empty .size file raised an
  unchecked NoSuchElementException that escaped the surrounding catch.
* validateFile checked only the first hash sidecar it found, ignoring the rest.

New functionality:

* validateFile now really verifies MD5, SHA-1 and SHA-256 instead of throwing
  UnsupportedOperationException. Sidecars are written as bare lowercase hex and
  parsed tolerantly, so a file downloaded verbatim from a server in coreutils
  or BSD layout is also understood. A sidecar that cannot be parsed is skipped
  with a warning rather than failing an otherwise good download.
* ETagPolicy lets an ETag that is a bare hex digest be recorded as a checksum
  without a second request. files.wwpdb.org and files.rcsb.org return the
  content MD5 as the ETag, so every download from the wwPDB archive now gets a
  real integrity check for free. The <mtime>-<size> ETags used by the EBI
  servers contain a dash and can never be misread as a digest; a test pins that.
* downloadFileWithValidation downloads and validates over a single connection.
  The previous pattern opened one connection to read Content-Length and another
  to fetch the bytes, so the recorded size described a different response than
  the one written; if the resource changed in between, the cache entry was left
  permanently failing validation. Content is digested while streaming to a temp
  file and only moved into place once length and checksum check out.

LocalPDBDirectory uses the new single-connection download, and its two-character
directory hash is promoted to the reusable getMiddleHash(String). That hash
deliberately counts from the end of the identifier so that both spellings of an
entry land in the same bucket: 1cbs and pdb_00001cbs both give "cb", where
counting from the start would file the extended form under "db".

Defaults change slightly: the existing four-argument createValidationFiles
overloads now use ETagPolicy.USE_IF_HEX_DIGEST, so callers start recording
checksums where the server offers one. Targeted at 7.3.0.

download.cathdb.info now answers plain http with a 301 to https.
HttpURLConnection follows redirects within a protocol but deliberately will not
follow one that switches http to https, so the download never reached the real
file. downloadFileFromRemote read the response with a bare openStream() and no
status check, which meant the body of the 301 was written into the local cache
as though it were classification data. Parsing it produced no domains, and the
first sign of trouble was a NullPointerException much later, far from the cause:

    CathDomainTest.test:40 NullPointer
      Cannot invoke "CathDomain.toCanonical()" because "domain" is null

This has been failing on every pull request since the redirect appeared.

Two changes. CATH_DOWNLOAD_URL now uses https, which fixes the immediate
breakage. And the hand-rolled copy loop is replaced by
FileDownloadUtils.downloadFileWithValidation, so a non-2xx response throws
instead of being cached, and a redirect that changes protocol is logged
explicitly rather than passing silently. That is what turns this class of
failure from a mysterious NPE into an error naming the URL and the status.

The shared download also records the byte count it actually wrote, so CATH files
now get size validation they never had; download.cathdb.info sends no ETag, so
there is no checksum to record, but the size check alone would have caught a
truncated file.

CathDomainTest passes again, in about 11 seconds.

downloadChemCompRecord read the response body without ever checking the status.
A 4xx or 5xx already failed safely, because getInputStream() throws for those,
but a redirect did not: when the JDK declines to follow a 3xx - which it always
does when the redirect changes http to https - getInputStream() returns the body
of the redirect instead. That body is short but not empty, so the "did we read
any lines" check accepted it, gzipped it, and stored it under the component's
name. Every later lookup then read that back and failed to parse it, far from
the request that caused it.

This is the same failure that took the CATH downloader out when
download.cathdb.info moved to https, and files.rcsb.org would do the same to us
the day it stops serving plain http.

Checking the status closes it. The download is left otherwise alone: it
re-compresses the response as it writes, so the local .cif.gz is not a byte copy
of the remote .cif and downloadFileWithValidation cannot stand in for it here.