FilterX copy-on-write for mutable objects

[MrAnno]

Depends on #346

Copy-on-write and FilterXRef

Deep-copy assignment (the .something = , ["something"] = , something =, something += operators) is an essential feature of the FilterX language, making it easy to trace and understand how values change.

However, copy (especially deep-copy) is expensive, so this PR aims to fix the performance bottleneck by introducing copy-on-write for mutable objects.

To achieve CoW semantics without introducing endless changes in the filterx folder, FilterXRef has been introduced.
References are currently not part of the FilterX language (hopefully, they never will be). FilterXRef is used only internally to reference the same FilterXObject from multiple locations (variables, other types of assignments).
For this reason, FilterXRef pretends to be a FilterXObject, but it's not a real FilterX type.

FilterXRef transparently propagates operations (virtual function calls) to the referenced value, but it also makes sure that the value is copied on the first write operation in case multiple references exist.

FilterXRef is created only for mutable objects, and only when they are needed: around assignment-like operators;
this and its FilterXObject behavior was the key to avoid polluting all code paths with references.

Implementation concerns

Unfortunately, FilterXRef can only be transparent when virtual calls are used.
We use a lot of downcasting and isinstanceof() calls for logical and performance reasons.
Where explicit downcasting is needed, filterx_ref_unwrap() must be called to extract the original object. The extracted object must only be used locally (short-term, without referencing or storing it anywhere).
This is ugly and hard to maintain, but downcasting is the original problem here. A safety check has been added to filterx_object_is_type() in order to detect if we forget to call unwrap().
(And since FilterXRef is only for mutable types, I could avoid polluting the codebase with those calls where immutable downcasts were used.)

Everything sounds simple in theory, but debugging this with GDB is a nightmare if you try to catch a bug.

Current limitations

Full CoW on subscript and attr operators (.something, ["something"]) of JSON objects is currently not implemented.
I've tried to make it work, but it requires a complete redesign of how we cache JSON subobjects (or alternatively, we need an internal representation for dicts and lists without using the json-c library). This will be implemented later.
For now, such operators make unnecessary copies (CoW only partially works on them).

[MrAnno]

I've written a longer PR description. The diagram may be hard to understand due to the lack of context, but we can talk about it IRL.

[OverOrion]

LGTM, thank you! 🚀
Notes for the other reviewers:
I checked the unwrap_ro usages, I kindly ask you to do the same to make sure the RO version is not mutated anywhere.

The merge-base changed after approval.

[alltilla]

This looks awesome. I would like to recheck the downcast commit one more time, then approve and merge will come :)

[MrAnno]

Calling unref() on an unwrapped object is also dangerous.

I am considering freezing those objects or replacing their unref() method (separate PR should be enough)...

The merge-base changed after approval.

[alltilla]

Approve. @MrAnno Could you kindly rebase this to main? GitHub does not let me merge this way. Thanks!

[MrAnno]

Done, thanks.