Fix detection of popup UI close for Chrome MV3

[kzar]

The extension's popup UI allows the user to do several things,
including disabling/enabling protections for the current website.

When the user disables protections for a website, the website is added
to the allowlist. After a delay (or when the user clicks away) the
popup UI is closed and the website is reloaded automatically. Until
now, that worked by listening for the window.unload event, and then
using the chrome.extension.getBackgroundPage() API to fetch the
background page before triggering the unload function in the
background.

With Chrome Manifest v3, the getBackgroundPage() API is no longer
available and so a different approach must be used. We're now opening
a messaging connection to the background, sending through user actions
as they happen, then finally having the background detect when the
connection is closed (popup is closed) to trigger any corresponding
actions like reloading the active website.

1 - https://developer.chrome.com/docs/extensions/mv3/mv3-migration-checklist/#api-background-context

Reviewer: @sammacbeth
CC: @jdorweiler

Steps to test this PR:

Chrome MV2

1. Check that the developer tools panel still works OK
2. Check that when you allowlist a website in the popup, the website is refreshed automatically.
3. Check that when you don't toggle allowlist for a website in the popup, the website is not refreshed automatically.

Chrome MV3

1. Check that when you allowlist a website in the popup, the website is refreshed automatically[1].
2. Check that when you don't toggle allowlist for a website in the popup, the website is not refreshed automatically.
3. Open popup, allowlist a website, wait 5+ minutes for background SW to close, close popup UI and check website is reloaded automatically.

1 - Note that the actual allowlisting of the website won't work until #1464 lands.

Automated tests:

• Unit tests
• Integration tests

Reviewer Checklist:

• Ensure the PR solves the problem
• Review every line of code
• Ensure the PR does no harm by testing the changes thoroughly
• Get help if you're uncomfortable with any of the above!
• Determine if there are any quick wins that improve the implementation

PR Author Checklist:

• Get advice or leverage existing code
• Agree on technical approach with reviewer (if the changes are nuanced)
• Ensure that there is a testing strategy (and documented non-automated tests)
• Ensure there is a documented monitoring strategy (if necessary)
• Consider systems implications

[sammacbeth]

The looks good to me. I just had one comment about cleaning up dead listeners, but it's not a blocker.