Proposal: new "halation" module for warm chromatic glow around highlights

New processing module (IOP).

Is your feature request related to a problem?

darktable can already spread light out of the highlights with bloom, but bloom works purely on luminance (it blurs and screen-blends the L channel only). It cannot reproduce the warm, chromatic bleed that is characteristic of
analog film halation — where light passes through the emulsion, reflects off the film base and re-exposes mostly the red-sensitive layer, leaving a reddish-orange glow around bright edges. Today this look requires manually
stacking several modules (highlight mask + blur + warm tint + screen blend), which is fiddly and hard to reuse.

Describe the solution you'd like

A small, self-contained creative module called halation that:

1. extracts the highlights above a threshold,
2. blurs them into a soft halo (box blur, same approach as bloom),
3. screen-blends the halo back onto L, and
4. tints the bleed toward a configurable warm hue in the a/b plane, weighted by halo coverage.

Proposed controls: size, threshold, strength, hue (default ~25°, film-like red-orange) and saturation. It sits in the effects group, operates in Lab (display-referred, next to bloom), and supports blending/masks.

Why a separate module instead of extending bloom?

The defining feature of halation is the chromatic bleed (the warm tint following the blurred highlights), which is orthogonal to what bloom/diffuse/blurs do. I kept it separate to avoid changing bloom's parameter set and legacy
behavior, but I'm happy to discuss folding it into an existing module instead if that's preferred.

Additional context

I already have a working implementation against the 5.4.1 tree (modeled on bloom.c), with introspection-based params and GUI, verified end-to-end via darktable-cli (the module loads, enters the pixelpipe and produces the
expected warm halo around highlights). It is currently CPU-only.

Before opening a PR I'd like to check whether you'd consider this module at all, and if so I'm willing to do the remaining work to bring it up to standard and to maintain it going forward:

• add an OpenCL path (process_cl + .cl kernel),
• provide a sensible default preset,
• add a user-manual entry in dtdocs,
• follow the coding style / clang-format.

Happy to move the discussion to the dev Matrix channel if that's better. Thanks!

Start by comparing the existing bloom.c implementation and the working CPU module described in the issue, then inspect the darktable-cli behavior. Done means an OpenCL process_cl path and .cl kernel, a sensible default preset, a dtdocs manual entry, and code matching the project style and clang-format expectations.