Refactor about:torconnects relation to TorConnectParent

When looking at the code for aboutTorConnect.js and TorConnectParent.jsm for #41608 (closed) and #41384 I realised that they have a strange mix of signalling.

1. Each "about:torconnect" tab listens for "torconnect:state-change" from their TorConnectParent, which is passed on from TorConnect.
2. Each "about:torconnect" tab sends events to TorConnectParent that are essentially just passed on to TorConnect to change its state.
3. Each "about:torconnect" tab regularly sends out "torconnect:set-ui-state" to their TorConnectParent, and then this state is saved for all instances of TorConnectParent. This state is only read by newly created "about:torconnect" tabs via "torconnect:get-init-args".
4. There are 3 actions that are not linked to the TorConnect state, which sends out "broadcast-user-action" to their TorConnectParent, which then broadcasts this to all instances of TorConnectParent, and each "about:torconnect" then receives "torconnect:user-action" to update their state.

I think basically 1 and 2 are there to interact with TorConnect, and as a side effect if you have multiple "about:torconnect" tabs they will mostly stay in sync. 3 and 4 seem to be added to fill in the gaps to keep each tab absolutely in sync.

Since we want this tight synchronisation between each "about:torconnect" tab, I think it would make more sense to shift all the UI state information to the TorConnectParent class, which is shared by each instance. I.e. drop aboutTorConnect.uiState and shift the control out of the child and into the parent. And the relation would be:

1. Each "about:torconnect" tab listens to a state change event, and it tells the tab all the information it needs to "paint" itself. All instances receive this at the same time.
2. Each "about:torconnect" tab sends user interactions (clicking a button, selecting a country, etc) to the TorConnectParent.

NOTE: things like user focus should be managed independently by each "about:torconnect" tab.

This area might need some refactoring anyway to address #41384 so I might do this just before, or in combination.