ESRF id31 new detector default and Q plot in all SIXC reference frames

[tifuchs]

Brings the ESRF ID31 beamtime work onto master, together with a reworked
experimental reciprocal-space (Q) display.

master is fully contained in this branch, so it merges without conflicts.

Breaking changes

• HDF5 file locking is now disabled by default (HDF5_USE_FILE_LOCKING=False),
  so files still open for writing by the acquisition system can be read. A
  manually set environment variable still wins, and --hdflocking / -l
  restores the previous behaviour.
• ID31-style scan objects are recognized from the configured backend class
  instead of a hardcoded list of beamtime ids. This fixes the id31_default_p4
  backend, which the old list did not cover, and makes new ID31 beamtimes work
  without code changes. Custom backends whose class name does not contain
  BlissScan are no longer treated as ID31-style even if their beamtime id was
  previously listed.

ID31 beamline support

• BlissScan_EBS_p4 backend for the Pilatus4 detector, an example backend under
  examples/backend/ID31_EBS_p4_backend.py, and the ch8153 beamtime.
• Default backend is now id31_default_p4; the fallback geometry describes a
  Pilatus4 4M CdTe. The manual backend selector now follows
  backends.default_beamtime instead of a second hardcoded default.
• HDF5 files that are still being written can be refreshed from the GUI.
• Maximum/sum images are untoggled when the image number changes, and their
  toolbar icons no longer get out of sync.

Experimental Q-plot

A Q-plot toolbar action displays the image in reciprocal space, with a
drop-down selecting the frame: Q_alpha (default), Q_lab, Q_omega,
Q_chi, Q_phi and Q_cryst. It lives in orgui.app.qconversion —
deliberately in the application layer, not in orgui.datautils.xrayutils, so it
is not mistaken for production reciprocal-space code, and it is marked
experimental in the UI, the module and the docs.

Why it does not simply use pyFAI's fiber units. pyFAI's
sample_orientation is the EXIF dihedral group acting on the image array, so it
only spans quarter turns, whereas orGUI's azimuthal reference is continuous. An
implementation based on that flag is correct only at exact multiples of 90
degrees — at an azimuth of 45 degrees it is off by several inverse Angstrom. The
azimuth is therefore passed through tilt_angle, and because pyFAI composes the
incidence and tilt rotations about fixed axes while in orGUI the azimuth rotates
the alpha axis itself, orGUI supplies FiberIntegrator with its own
UnitFiber definitions. pyFAI still performs the rebinning.

Performance. The conversion collapses into a single affine relation and is
evaluated by a new pybind11 extension, _qconversion_cpp. A 6.2 megapixel
Pilatus 6M image converts in ~50 ms instead of ~740 ms, bit-exact against the
numpy reference; a numpy fallback is used when the extension is not built. The
pyFAI integrator is reused while the conversion is unchanged, so stepping
through images no longer resets it per image.

numexpr is deliberately not used: version 2.11.0 returns wrong results for a
small fraction of multi-threaded evaluations of this kind of expression
(reproducible with no orGUI code involved, ~3/200 evaluations).

Other GUI changes

• The Q-plot stays switched on and is rebuilt when the image, the max/sum
  selection, the frame, the machine angles, the energy or the orientation matrix
  change.
• The position readout shows HKL as one bracketed triplet and the momentum
  transfer of the selected frame as Q[alpha], Q[lab], … with five decimals.
  Field size hints are matched to their content so the triplets are not elided.
• Fix: cancelling or resetting the machine parameter or crystal parameter
  dialog now restores the configuration that was active when the dialog opened.
  Both dialogs apply every edit immediately, so restoring the widgets alone left
  the discarded configuration active.

Testing

New tests cover the conversion against QAlpha per pixel for flat and tilted
detectors at azimuths that are deliberately not multiples of 90 degrees, that
Q_phi reproduces anglesToHkl and Q_cryst reproduces B·H, that the
compiled kernel matches the numpy fallback, the integrator cache does not serve
stale coordinates, and the dialog-cancel and readout behaviour.

Notes for reviewers

• meson.build gains _qconversion_cpp, so a rebuild is needed for the fast
  path. Without it the numpy fallback runs automatically (~135 ms for 6 Mpixel).
• The Q_omega frame is mathematically indistinguishable from `Q_

[Finnjek]

Looks very nice! I have tested the Q conversion with several ID31 datasets. Very fast conversion compared to the old pyFAI method. However I have found some minor issues that may need to be addressed before merging to main:

• the cursor live values shown under the plot are wrong when in Q-Plot mode. This was the same in the old pyFAI conversion and is because the X and Y value are linked to the Q_parallel and Q_perp values instead of pixels. We should change the labels 'X' and 'Y' and give correct values for HKL, delta and gamma when in Q-plot mode.
• When toggling the Q-Plot button, the plot orientation (x-origin and y-origin) sometimes doesn't roll back to its original value.
• Also, the Q-Plot image always has its origin in the bottom left corner, even if the detector image is differently oriented. We could however leave it like this, as this is much clearer and only very few (crazy) people do experiments in downward scattering orientation.
• The new id31 backend class has no 'BlissScan' in its name and is therefore not recognized by the isID31 option in orGUI.py, for example when loading segmented scans.
• Maybe replace the button icon that is currently text 'Q-plot' to a thumbnail of a capital Q with a vector arrow to have a uniform style?

[tifuchs]

Thanks, I completely forgot about the issue with the x y pixel conversion for Q.

Unsure about the Q-plot orientation behavior. The solution now tries to adapt automatically, but this might cause problems.
We might need to add a manual setting for that. Let's see how it works in the field.