In case a part of an override hierarchy would still be linked data, and
there would be other liboverride hierarchies sharing usage of that same
linked data, trying to create a partial override of that linked data
into a hierarchy would create very unreliable results.
This commit now only process each ID at most once, to ensure that the
liboverride will only be put in one liboverride hierarchy.
This is only a partial fix, results now should at least always be
valid. However, due to inheritently broken Outliner code when it comes
to same data in more than one path of the tree, the place where
(hierarchy in which) the new liboverride will be created is currently
'random' and unpredictable from user perspective.
This commit contains some code to try to alliviate that (by enforcing
processing of the active elements first), but unfortunately this does
not work either.
9f1a4a2e3f