clutter/stage: Don't do newly queued relayouts after allocation cycle

While it's strongly discouraged, it is possible to queue a new relayout of an actor in the middle of an allocation cycle, we warn about it but don't forbid it.

With the introduction of the "shallow relayout" API, our handling of those relayouts silently changed: Before introducing "shallow relayouts", we'd handle them on the next stage update, but with the priv->pending_relayouts hashtable and the priv->pending_relayouts_version counter, we now do them immediately during the same allocation cycle (the counter is increased by 1 when queuing the relayout and we switch to a new GHashTableIter after finishing the current relayout, which means we'll now do the newly queued relayout).

This change in behavior was probably not intended and wasn't mentioned in the commit message of 5257c6ec, so switch back to the old behavior, which is more robust in preventing allocation-loops. To do this, use a GSList instead of GHashTable for the pending_relayouts list, and simply steal that list before doing the relayouts in _clutter_stage_maybe_relayout().