We can't assume all our siblings are alive because they may very well be in the
free list too.
This tempts to happen when the rule nodes are destroyed as part of the last GC,
the one that runs in the root destructor.
Also, properly put the next sibling back into the list when the rules are GCd.
RuleTreeDeclarationsIterator would yield &PropertyDeclaration
with the lifetime of the rule tree, but the reference would only
be valid as long as the iterator was holding the corresponding lock.
The lock would be released when the iterator’s `.next()` method
moves to the next rule tree node, or when the iterator is dropped.
Also change apply_declaration to not require a `Clone` iterator
(since closures unfortunately don’t implement `Clone`).
Instead have it take a callable that returns a fresh iterator.
This patch introduces infrastructure for the rule tree, and constructs it.
We don't use it yet, nor have good heuristics for GC'ing it, but this should not
happen anymore once we store the rule node reference in the node.
I haven't messed up with memory orders because I want to do a try run with it,
then mess with them.
Take down the ApplicableDeclarationsCache, use the rule tree for doing the cascade.
