Switch remaining CSP-vulnerable main world script injection to scripting API

[ghostwords]

We already migrated most but not all uses of window.injectScript() to the scripting API:

• c42ec23?w=1
• b5f4d16?w=1
• 30b5b4b?w=1

Let's migrate the rest (search for injectScript in the MV3 branch).

The main problem with window.injectScript() is that it is subject to page CSPs. This means learning from canvas fingerprinting and local storage is broken on sites with restrictive CSPs (like this very site probably). We pollute the page dev tools console and/or the Errors button on chrome://extensions/ when this happens.

Related issues: #1793, #1865

[ghostwords]

One issue is that the two remaining uses of injectScript() both pass a parameter to the main world script, so that the main world script can send messages back to the content script using CustomEvents with a prearranged, random ID, to make message interception a bit harder.

There's been lots of discussion of adding parameters (and secure communication) to registered main world scripts (for example, w3c/webextensions#284 (comment) and w3c/webextensions#536 (comment)) but so far nothing tangible came of it? There may also be workarounds worth investigating in w3c/webextensions#78 (comment).

Edit: There are now two relevant API proposals, dom.execute() (synchronous cross-world content script injection) and dom.createPort() (secure communication).