Defer tab_changed signal when removing children from TabContainer nodes

[YeldhamDev]

Reverts #63145 by resolving the problem with a different approach.

While it still removes the tab immediately, the signal emission itself is deferred. This means functions that do operations which modify the tab bar still work correctly when called right after remove_child(child), while stuff that relies on the signal also works as well.

This implementation also avoids a bug from the older version when doing a operation that affect the tab bar right when the tab_changed signal is called.

I tested it with the bugs closed by the previous PR and they seemed to remain fixed, but I remember also not being able to reproduce the bug even before the old fix, so more testing is required.

[KoBeWi]

When you remove multiple tabs, the signal is queued for each removal and then fired all at once. But idk if it has undesired effect 🤔

[YeldhamDev]

When you remove multiple tabs, the signal is queued for each removal and then fired all at once. But idk if it has undesired effect

Really can't think of a better solution. The only thing that would truly take care of all corner cases is if there was a callback for just after the child was removed.

[YeldhamDev]

@KoBeWi One thing that could be done is go back to the current solution, but use an array instead of a single-node variable. Feels hacky, but I think that would solve the previous problem without firing the signals all at once.

[KoBeWi]

Or you can add queue_tab_changed() function that ensures the signal is emitted once.

[YeldhamDev]

That would still make the signal always fire at the last moment of the frame, and this may be undesirable when doing further modifications to the tabs all at once.

[akien-mga]

CC @Rindbee.

So which PR do we favor between this one and #67928?

[Rindbee]

I prefer #67928, there are multiple signals emitted during the remove_tab call, I'm not sure if they can be blocked from being emitted.

[akien-mga]

Superseded by #67928.