Introduce a new `$tabchange` event that is emitted by UI Event

Permit users to react to a "tab change" to (for example) populate the likes of a ui-dropdown upon tab change when a page "Layout" is set to "Tabs"

See below referenced issue for details.

---

_Originally posted by @joepavitt in [#1669](https://github.com/FlowFuse/node-red-dashboard/issues/1669#issuecomment-2915919542)_

> Just worked through this with @Steve-Mcl - it's not straight forward, but I will do my best to articulate:
>
> - The issue arises from when and how we store "state" on a widget. When you send a `ui_update` request, we (a) send it to the client, where any actively rendred widgets receive it and action it, and (b) store the state server-side in our "state store". When a widget then first rendered in the UI, we have a `widget-load` event which reads the "state" from the store, and displays the updated options. This works correctly.
> - However, we _only_ do this for widgets that have a _shared state_ across all client connections. If the "UI Dropdown" is toggled _on_ in the "Client Constraints" tab for Dashboard (such that each dropdown has unique state per user), then this message is _only_ sent to the front-end connection specified in `msg._client` (which UI Event includes), and is not stored server-side. This means that the client-side widgets not yet rendered, e.g. dropdowns on other tabs, do not receive the request to update their options, nor is it stored server-side.
>
> **Workarounds:**
>
> - Make the `options` universal across all client connections, you can do this in one of two ways:
> 1. Un-toggle `ui-dropdown` from the "Client Constraints" tab in the Dashboard sidebar. This will mean that all dropdowns share state across all client/user connections.
> 2. Add a `change` node in _after_ the `ui-event` node, and `Delete` the `msg._client` object. This will mean that only this property and dropdown will share state across all client connections
> - We introduce a new `$tabchange` event that is emitted by UI Event. This will fire the request to dynamically populate the options (and the same for any other widget in question) which gives the coverage needed.
>
> The latter workaround is imo the correct fix here as it provides coverage across all of the user cases