Refactor `peerMonitoringLoop` and outbound governor `deactivatePeerConnection` calls

[bolt12]

• The deactivatePeerConnection function is currently employed in two contexts, both responsible for mux termination. However, mux termination should be exclusively handled by the peerMonitoringLoop upon detecting a Hot -> Cold demotion.
• The role of deactivatePeerConnection in the outbound-governor should be limited to waiting for the termination of all hot mini-protocols and then either returning or throwing an exception.
• Some refactoring is recommended to streamline these processes and prevent similar issues in the future.

[coot]

The role of deactivatePeerConnection in the outbound-governor should be limited to waiting for the termination of all hot mini-protocols and then either returning or throwing an exception.

deactivatePeerConnection is to demote a hot peer to a warm one, not just to block on the transition. The outbound-governor is the active component which needs to have ways to promote and demote connections.