Fixes raster masks not being properly released

[masterpiga]

What this fixes

is_raster_mask_used() only ever checked the table membership — never whether the consumer is deleted, de-synced, in raster mode, or even enabled — so a disabled consumer could keep the producer publishing and invalidating all downstream cachelines every run.

The fix

dt_iop_prune_stale_raster_users now drops a registered consumer when any of these holds — all evaluated without ever dereferencing a freed pointer:

• not in the module list → instance deleted
• sink.source != this → de-synced
• !sink->enabled → disabled
• !(mask_mode & DEVELOP_MASK_RASTER) → not in raster mode

The approach is self-correcting: re-enable a previously disabled module (or switch it back to a raster mask) and commit_blend_params re-registers it before the next prune, so a producer resumes publishing exactly when a real consumer needs it.

Should it wait for 5.8 (or 5.6.1)?

@TurboGit @jenshannoschwalm you be the judge. Unless I overlooked something very obvious, it is a pretty inoffensive change that brings significant improvements.

Co-authored with Claude.

[jenshannoschwalm]

Thanks

1. Nicely fixes expensive writing rastermasks and pixelpipe cache handling if early history steps declared using the rastermask and late history did not. Until now you had to compress history to achieve this. I had an in-depth look at it, tested and indeed seems to be very safe.
2. why not static _iop_prune_stale_raster_users() as it`s used exclusively in pixelpipe_hb.c and there seems to be no other use case?

[masterpiga]

2. why not static _iop_prune_stale_raster_users() as it`s used exclusively in pixelpipe_hb.c and there seems to be no other use case?

Makes sense, I undid the changes to the public api.

[TurboGit]

I tend for waiting for 5.8 to stay safe for the release.