The condition type was able to miss transition starts of very fast
conditions (e.g. Cut) when the selection "Any transition" was made.
In that case no signal handler was installed (as the condition type
might change) and only the transition scenes were compared at the time
of the condition check.
If that moment where the transition scenes differ was missed no
transition start was recognized.
Additionally, the "Transitioning to" and "Transitioning from" checks
faced a similar issue, if the scene transition was happening so fast,
that the condition check was not performed during the time of the
transition.
This was done to enable users to to use higher precision values in the
"Audio" condition type.
Previously, the UI would reset the selected values to the minimum value
possible to display in the volume meter widget, which was -60 dB.
A crash could occur if the plugin window was closed and reopened and a
new resource was added to either the Variable, Action queue, Websocket,
or Twitch tab.
No context object was provided to the signal handlers.
The signal provider is intentionally not deleted when the UI is closed.
Because of this, the signal connections were never cleared when the
underlying tab widget was destroyed.
So, in the case of closing and reopening the settings window, the old
connection with the outdated widget pointers would be called again.
Without this timeout the peak volume update, which was received last,
would be used permanently until the next update arrives.
This might only take place when the source produces audio output again.
OBS might very rarely not update _peak quickly enough when very low
intervals are configured on the General tab.
In that case _peak might be set to negative infinity still, which will
result in unexpected behavior, so we use the previously valid peak value
instead.
* The focus action no longer restores maximized windows
* The focus, maximize, minimize, and close actions will be performed on
all handles matching the given window title
This was already possible previously by inverting the logic with a
"not", however, this should it make it more obvious that this type of
check is possible.
