refactor: extract self-contained colormaps module

[patrickoleary]

refactor: use external trame-colormaps package for all colormap functionality

QuickView previously embedded ~1,400 lines of colormap state management,
color transfer function algorithms, log/symlog/discrete transforms, tick
computation, and colorbar/control-panel UI across view_manager.py,
components/view.py, app.py, utils/color.py, and utils/math.py.

All of that is now provided by the trame-colormaps package (>=1.0.0).
Each view creates a ColormapConfig instance that owns the VTK color
transfer function, mapper wiring, preset management, range computation,
and tick generation. The UI is a single HorizontalScalarBar widget call
per view, which renders the colorbar with an integrated popup control
panel for preset selection, scale modes, discrete banding, and manual
range override.

ViewConfiguration retains only layout fields (order, size, offset,
break_row, swap_group). State export/import separates layout config
from colormap config, with backward compatibility for older state files
that stored both in a single "config" key.

[jourdain]

Are you sure you still need that method? What is calling it?

[jourdain]

Code looks good. I'm just not sure about that update_color_range method.

[patrickoleary]

It is necessary. update_color_range is in view_manager.py and in trame-colormaps.py. The ViewManager method just loops over all views and calls view.colormap.update_color_range() on each ColormapConfig when quickview changes the data (_on_slicing_change and _on_downstream_change). The ColormapConfig.update_color_range() in trame-colormaps knows how to recompute (re-read the data array, rescale the CTF, reapply the preset). This split is correct. trame-colormaps doesn't know about QuickView's pipeline lifecycle, so QuickView triggers the recompute at the right moments.