transaction: make transaction collapsing smarter with > 2 views

Sway maintains a list of pending transactions, and tries to merge
consecutive transactions applying to the same views into one. Given
a pending transactions list on views {A, B, C} of:

  A -> A' -> A'' -> B -> B' -> B''

Sway will collapse the transactions into just A'' -> B''. This works
fine when doing things like resizing views by their border. However,
when interactively resizing layouts like H[V[A B] C], we end up with
pending transaction lists like:

  A -> B -> C -> A' -> B' -> C' -> A'' -> B'' -> C''

Previously, Sway would not be able to simplify this transaction list,
and execute many more transactions than would be necessary (the final
state is determined by {A'', B'', C''}).

After this commit, the transaction list gets simplified to A'' -> B'' ->
C'', resolving performance problems (that were particularly noticeable
with high-refresh-rate mice).

Fixes #5736.

sway/desktop/transaction.c

@@ -358,11 +358,20 @@ static void transaction_progress_queue(void) {
 	// If there's a bunch of consecutive transactions which all apply to the
 	// same views, skip all except the last one.
 	while (server.transactions->length >= 2) {
-		struct sway_transaction *a = server.transactions->items[0];
-		struct sway_transaction *b = server.transactions->items[1];
-		if (transaction_same_nodes(a, b)) {
+		struct sway_transaction *txn = server.transactions->items[0];
+		struct sway_transaction *dup = NULL;
+
+		for (int i = 1; i < server.transactions->length; i++) {
+			struct sway_transaction *maybe_dup = server.transactions->items[i];
+			if (transaction_same_nodes(txn, maybe_dup)) {
+				dup = maybe_dup;
+				break;
+			}
+		}
+
+		if (dup) {
 			list_del(server.transactions, 0);
-			transaction_destroy(a);
+			transaction_destroy(txn);
 		} else {
 			break;
 		}