Refactor `peerMonitoringLoop` and outbound governor `deactivatePeerConnection` calls

- 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.