scripts: policy-node: don't process when linkables are activating

Linkable activation takes some time, so they are not in sync with nodes at all times, and they do not activate in the same order as nodes. Consequently, cross-references (e.g. node.target) may be incorrectly resolved, if target and targeting nodes appear rapidly after each other.

To fix this, wait for all pending linkables to complete activation (success or fail), before handling any linkables in policy-node.

---

Alternative to !321 (closed) and !322 (closed) Here we instead suspend all processing in policy-node with pending linkables, which also avoids rescans from metadata changes causing problems.

Here we use active-features gobject flag to know which linkables are still pending.

To have policy-node stop processing when linkables are pending, create-item needed to be moved into it, as one needs to know if there are unregistered linkables waiting for activation. Some nodes may fail linkable configuration, and never result to linkables (even if failed flag was added), which policy-node cannot otherwise know.

In principle create-item could set some global flag (which?) to indicate whether linkables are pending. However, the object monitors in a separate create-item and policy-node are not guaranteed to be synchronized (idle callbacks apparently), so race conditions with such global flag should occur.

I also added an error timer, in case some items fail to activate, or take a long time to do so. This is because if such bug exists, it will be hard to figure out what is going on from user reports, because policy-node stops processing and the sound system will appear to hang.

Unfortunately, with the serial checks added in pipewire (see pipewire!1170 (closed) why) which fixes the pw_registry_bind/destroy race conditions, some linkable takes 30sec to activate, apparently when WP fails to bind some ports. Trying to still find out why... Resolved.