Fetch, cache and display electron density and cryo-EM maps - #1134

Adds loadDensityMap and clearDensityMaps to JmolPanel, the single point every
viewer in the module already goes through, so a map fetched by DensityMapCache
can be contoured with one call. Surfaces are given stable ids so they can be
addressed or removed individually, and the state that "Reset Display" restores
is re-saved afterwards; otherwise the button would silently discard the map the
user had just asked for.

Three things had to be established by experiment against Jmol 14.31.10 rather
than assumed, and each changed the implementation:

* Option order in the isosurface command is load-bearing. With "mesh nofill"
  placed before the file name, Jmol accepts the command, reports no error, and
  draws nothing whatsoever. It has to follow the file name.

* A negative sigma does not contour at a negative level. Jmol reserves negative
  sigma for its own internal signalling, so "sigma -3.0" silently contours at
  the default level instead: the intended red lobe of a difference map came out
  identical to the blue one. Difference maps are therefore drawn as a single
  signed surface, which also matches Jmol's own shortcut for them.

* A density server response carries both the 2FO-FC and FO-FC blocks, and Jmol
  chooses between them by testing whether the file NAME contains "&diff=1". That
  marker normally arrives in the URL query string, which a cached local file does
  not have. Appending it to the file URL does not work, and neither does the
  "#diff=1" form the reader's own comment suggests: both were measured and both
  returned the 2FO-FC block or nothing. Embedding the marker in the file name
  does work, so the cache exposes the difference map under a companion name,
  hard-linked to the same bytes where the filesystem allows it.

Verified by contouring the real cached files headlessly: the 2Fo-Fc map at 1
sigma gives cutoff 0.356 over a -1.31 to 3.78 range, and the difference map at 3
sigma gives 0.374 over -0.69 to 0.85 - a different data block, which is what
proves the marker works rather than merely being accepted.

A map that cannot be contoured without a Fourier transform is rejected with an
explanatory exception rather than producing an empty surface.

Puts the feature in reach from the alignment viewer's View menu. The fetch runs
on a SwingWorker: even the smallest source is a few hundred kilobytes and a
full-resolution map can be far larger, so fetching on the event dispatch thread
would freeze the window for the duration.

Requests are built with allowNonRenderableFormats(false), which keeps the map
coefficient source out of the chain automatically rather than relying on the
viewer to notice it cannot draw the result.

When nothing is available the dialog explains why rather than listing HTTP
codes: for an entry whose every source returns 404 the likely reason is that no
structure factors were deposited and there is no associated EMDB map, which is
worth saying plainly. The per-source detail is still shown underneath.

AbstractAlignmentJmol gains getFrame() and setStatus() so a listener in the
neighbouring package can own its dialogs and report progress; both were
previously reachable only as protected fields.

DemoShowElectronDensity displays 1CBS with both maps clipped around the bound
retinoic acid.

Forty-three unit tests run with no network at all. The chain tests use stub
providers, so the behaviour that matters can be pinned exactly: a 404 falls
through to the next source, a too-large map falls through as well, and anything
else aborts. That last one is the point of the design - reporting a dropped
connection as "this entry has no density" would be worse than failing.

The offline set also pins the two-character directory rule against both
spellings of an entry (1cbs and pdb_00001cbs must land in "cb", not "db"), that
every source and kind combination maps to a distinct file, and that a LOCAL_ONLY
request is served entirely from disk with every server pointed at a dead port.

Six integration tests exercise the real services for a couple of megabytes in
total. The cryo-EM path is covered without downloading the 116 MB map: the EMDB
entry is resolved, the author contour level checked against its known value, and
the size guard then declines the full map before any of its body is transferred.
The coefficient test corrupts a downloaded file afterwards to confirm the
ETag-derived MD5 actually catches it rather than merely being recorded.

Writing the header check turned up a real bug: isCcp4 rejected any file shorter
than a CCP4 header, but a gzipped map compresses to a small fraction of the
header it contains, so small EMDB maps would have been rejected as invalid. The
length shortcut is gone; reading decides it.

The <table summary="..."> form is obsolete: the summary attribute was removed
in HTML5, and javadoc has generated HTML5 since JDK 15, so doclint rejects it
whenever it is switched on. The build sets -Xdoclint:none so this never broke
CI, but it would surface in the release profile and the attribute does nothing
for accessibility any more.

A definition list suits a list of placeholders and their meanings better than a
two-column table in any case.

The project is migrating to jupiter, so tests added by this branch should
not arrive as JUnit 4.

Imports move to org.junit.jupiter.api, @before and @after become
@beforeeach and @AfterEach, and the seventeen assertions carrying a
message have it moved from the first argument to the last, which is where
JUnit 5 expects it.

The three assertEquals(expected, actual, delta) calls are left alone: the
third argument there is a floating point tolerance, not a message, and
that overload is unchanged between the two versions.

No pom changes: both modules already declare junit-jupiter-engine and
junit-jupiter-params.

The coefficients were fetched through the divided archive path, built from
the two-character hash and the identifier. That path stops being correct in
July 2027, when the PDB moves to extended identifiers and a per-entry layout
under data/entries/<hash>/<extended id>/, and every file name changes with
it. The documented download endpoint resolves an entry by file name instead,
so it survives the move untouched:

  https://files.wwpdb.org/validation/download/1cbs_validation_2fo-fc_map_coef.cif.gz

Verified against files.wwpdb.org, files.rcsb.org and files-beta.wwpdb.org:
all three serve it, in both the short and the extended spelling, and the
beta host already serves it from the new archive.

This was the only provider here that ever constructed a path. The density
servers, PDBe and the EMDB archive are addressed by identifier already, so
nothing else in the package is exposed to the transition.

The default host stays files.wwpdb.org rather than files-beta.wwpdb.org,
which is deliberate and worth recording. The wwPDB describes the beta host
as transitional: on 21 July 2027 the beta archive replaces the main one,
after which the beta URL is supported by redirection for three years.
Pointing at it would be the choice that has to be revisited, twice, while
the main host simply becomes the new archive. Nothing is given up by
preferring the durable name either: the two serve byte-identical files
today, checked across nine entries and agreeing even on which ones 404.
The beta host is kept as a constant precisely because it already holds the
post-2027 content, which makes it the way to test this endpoint against the
archive as it will be rather than as it is - and it resolves both spellings
there, so the endpoint's semantics survive the cutover.

The identifier spelling is left to PdbId. getId(true) yields the short form
where an entry has one and the extended form otherwise, which is what the
entries deposited after the four-character space is exhausted will need;
hard-coding either spelling would replace a rule that adapts with a constant
that does not.

Mirrors that publish directories rather than an endpoint stay reachable.
EBI is one - it offers no name-resolving endpoint at all - so the divided
templates remain as DIVIDED_*_TEMPLATE constants, and the layout that
arrives in 2027 is expressible as ENTRIES_*_TEMPLATE. Expressing the latter
needed the extended identifier inside a template, which nothing provided:
{pdbid_lc} yields whichever spelling PdbId chose, and the new tree needs the
extended one in two positions regardless. Hence {extid} in UrlTemplates.
A mirror of the new archive is now a configuration change rather than a
release.

The cache layout is deliberately unchanged. Its two-character directory is
a way of spreading files over directories, not a copy of the archive's own
layout, and getMiddleHash counts from the right hand end, so 1cbs and
pdb_00001cbs both land in cb - which is also the rule the wwPDB documents
for the new archive, confirmed against it: entries/cb/pdb_00001cbs/ resolves
and entries/bs/pdb_00001cbs/ does not. Nothing there needs attention in
2027. The javadoc now says why the cache is not laid out like the archive:
it cannot be a mirror, since the archive publishes structure factors and
coefficients but never grids, and writing density into a directory that is
meant to be an exact copy of upstream puts it at the mercy of the next
rsync --delete. Should that be revisited, every cached path is computed in
that one class.