MVR / BigStitcher dialogs reuse the previous call's values within a Fiji session #160

Observation

Two calls of imcflibs.imagej.bdv.fuse_dataset() in one Fiji session (headless, multiview-reconstruction
9.0.11), both N5 / OME-ZARR export:

1. with compression=Gzip and 32x32x16 blocks,
2. without compression / block keys in the macro string.

The second export was written with Gzip and 32x32x16 blocks as well, not with MVR's defaults
(Zstandard, 128x128x64).

Mechanism

Almost every MVR / BigStitcher dialog keeps its values in public static fields
(defaultCompression, defaultBlocksizeX_N5, ...) and updates them from each dialog it shows,
also in macro mode (checked with javap: 87 classes in multiview-reconstruction 9.0.11, 5 in
BigStitcher 3.0.8; only net.preibisch.mvrecon.Threads stores to ij.Prefs). Consequences:

• a numeric or choice key missing from a macro string takes the value of the previous call in
  the same Fiji session (or of the last GUI use), not the plugin's default
• a missing checkbox key is always off (ImageJ macro rule), independent of the GUI default
• restarting Fiji resets everything; each headless --run starts fresh, but a script calling a
  command several times (e.g. fusions at several resolutions, several registration passes) carries
  values over from call to call

Question for the imcflibs team

How should the wrappers deal with this?

• (a) Explicit values only where it matters (current state of the PR): e.g. fuse_dataset
  always passes compression and block sizes, with MVR's initial defaults. Shorter macro strings, but
  any key a wrapper omits silently depends on what ran before.
• (b) Every wrapper always passes every value of the dialogs it touches, defaults = the plugin's
  initial values. Reproducible regardless of session history; longer macro strings, and the
  defaults have to follow MVR / BigStitcher releases.
• (c) Reset the plugins' static defaults before a call (e.g. by reflection). Avoids long macro
  strings, but depends on internal field names and is fragile across versions.

(b) seems the most predictable for batch processing; it would also make the wrappers document the
full parameter set of each dialog.