kernel: use IS_MUTABLE_OBJ in UNB_LIST/ASS_LIST/ASSS_LIST

[fingolfin]

This might loose us a nanosecond here or there but it actually gains us something, too: uniform rejecting of write attempts to immutable lists, even if the lists are external objects.

[fingolfin]

OK, this causes test failures in GAP.jl and those are genuine failures. What needs to be determined is if they are to be considered a bug in there, or fair use which this PR incorrectly excludes (i.e. whether I should adjust this patch, or else GAP.jl).

Specifically, in GAP.jl we create special GAP objects with tnum T_JULIA which are thin wrappers around arbitrary Julia objects. These wrappers for simplicity always claim they are "immutable". The logic is that the wrapper is read-only, and can't be modified. However, it may very well point to mutable data on the Julia side. And we then implement adapt operations, so that wrapper[1] := 2; works if wrapper points to e.g. a Julia "vector" object.

However, elsewhere in GAP, immutability is not the same as read-only -- a concept vanilla GAP doesn't have at all, but HPC-GAP does.

Indeed, GAP component objects can be immutable and at the same time be writable (e.g. groups objects are immutable, but can store new attributes). When it comes to e.g. lists-of-lists, then "immutable" is meant to be "recursive". I can now see arguments both ways:

1. a T_JULIA object pointing to a writable Vector should not be marked as immutable, as it points to mutable data (like we don't have immutable lists containing mutable lists) -- what this PR would require in its current pure form
2. a T_JULIA object like a component object may reference other, mutable data (the current state)

Regarding point 2, the justification might be that "other component objects also do it" -- but I'm not convinced this is a good argument. Sure, a GAP group can "learn" new information, but that's not supposed to "change its mathematical content". This is still rather fuzzy, but I always took it as "all the extra data can be recomputed in principle, at least up to some equivalence" (e.g. asking for a Sylow $p$-subgroup may yield different ones due to randomization, but they are of course all conjugate).

But if I do wrapper[1]:=42; then this is different, one cannot "recompute" this, the user could have done wrapper[1]:=23; instead and we can't "know" that mathematically...

Here's another argument for the current state 2: if you do MakeImmutable(wrapper) or Immutable(wrapper) -- then what should happen? There is nothing like (Make)Immutable on the Julia side....

Here is my plan for now:

• first I'll run the package distro test suite against this PR, to see if it would break other packages
• then most likely I'll relax the change to only apply to internal objects, or possibly even to only internal list objects once more.

[ChrisJefferson]

So, while Immutable has always been a bit strange in GAP, I do agree I view things as "mathematically immutable", even if they can gain / change information (the most extreme case being stabilizer chains on groups)!

In terms of Julia objects, the same problem occurs, in principal, when we wrap any external object, my first stab at "rules" for things like Julia lists would be:

• Mutable by default
• If you mark a julia object as immutable, then it should 'act immutable' in GAP (you can't change it from the GAP side).
• If you change an object marked as immutable on the Julia side, then "bad things may happen", for example GAP might store that immutable list somewhere (attached to an object for example!), expecting it to stay immutable, then bad things might happen if you change it.

[fingolfin]

To be clear, the Julia "wrapper object" is immutable, it always points at the same Julia object for its entire life time. But the object it points to could be anything...

Anyway, I did run the package tests, and looking at https://github.com/gap-system/PackageDistro/actions/runs/15966396075 the changes in this PR would break ~16 packages (4 of those in the report are already broken right now), including most or all of the Homalg and CAP project, so it's a no-go anyway.

[fingolfin]

The new version should work, but it's less clear why we should merge it separately instead of as part of PR #6025 ...