Ensure correct unlocking of script editor history

[HolonProduction]

Related to and encountered while looking into #113042
Seems to be the same issue described in: Fixes #113502

The history can be locked, this is done when e.g. restoring the state from the history. Since this involves some deferred signals it can't be instantly unlocked. The approach till now was to unlock in some method that was connected to the deferred signal. But the signal is not consistently emitted. This PR instead defers the unlocking manually to ensure it always happens.

The fix relies on a certain behaviour of call_deferred.
The deferred call to emitting the signal happens before the deferred call to unlocking the history. So the method connected to the signal also runs before the history gets unlocked.

I added this to the documentation to ensure that this is considered stable enough to base a bugfix on it.

[ydeltastar]

The history tracking is still inconsistent when jumping to symbols or navigating back. Several functions, _save_history(), _save_previous_state(), _go_to_tab(), and _update_history_pos(); conflict with each other by writing overlapping entries to the history timeline or mixing past and present states, tabs and script lines.

For example, when jumping to a symbol in another script, _go_to_tab() writes the current state and then creates a new entry to the tab without a state (meaning the start of the script), then _save_history() adds another entry with a state, resulting in a history of current_line > first_line > current_line for a simple jump.

When moving back, _update_history_pos(), which should only read history, unexpectedly writes an entry too before moving to the previous one. _save_previous_state() also does its own thing, writing two entries to the history.

[HolonProduction]

I'm aware but it is not the point of this PR to address that. This perma locking thing makes debugging other history issues pretty rough so I want to have that sorted out first.