Replace origin with storage key for BroadcastChannel partitioning

[recvfrom]

This PR updates the BroadcastChannel portion of the HTML standard to have storage keys be used instead of origins when determining which browsing contexts should be able to have BroadcastChannel messages sent and received between them. Today, a storage key only consists of an origin, but it will (likely soon) include the top-level origin as well. Only using origin enables certain forms of cross-site tracking. For more details, see: https://privacycg.github.io/storage-partitioning/

This is related to #5803 (and will ultimately fix it once the Storage spec is updated to add top-level origin into Storage Key). Also, using Storage Key here instead of origin + top-level origin should make the standard more uniform across the storage APIs and messaging APIs that use this as a partition key (related: w3c/web-locks#74)

This is currently a WIP because it's blocked on: whatwg/storage#131 (addressed by whatwg/storage#132)

Also, the storage standard doesn't define a storage key comparison algorithm, so I'm just using 'equals' here. Is that sufficient or should we pursue adding a comparison algorithm to use? (addressed by whatwg/storage#134)

I will fill in all of the values below when making this PR no longer a WIP:

• At least two implementers are interested (and none opposed):
  • Chrome
  • Safari
  • Firefox
• Tests are written and can be reviewed and commented upon at:
  • https://chromium-review.googlesource.com/c/chromium/src/+/3424369 (NOTE: this adds a tentative test for partitioning BroadcastChannel by top-level site and origin, whereas the storage key spec hasn't been updated to include top-level site yet)
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1239274
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1755064
  • Safari: Not required - Safari appears to have already implemented partitioning
  • Deno (only for timers, structured clone, base64 utils, channel messaging, module resolution, web workers, and web storage): AFAICT this doesn't seem applicable (from looking at the code, it doesn't seem like any partitioning of BroadcastChannels is done/needed)
  • Node.js (only for timers, structured clone, base64 utils, channel messaging, and module resolution): AFAICT this doesn't seem applicable (from looking at the code, it doesn't seem like any partitioning of BroadcastChannels is done/needed)

(See WHATWG Working Mode: Changes for more details.)

---

/infrastructure.html ( diff )
/web-messaging.html ( diff )

[recvfrom]

I've address all prior feedback and updated this to leverage the new algorithms from the storage spec, so this PR should now be ready for a final review.

[annevk]

One thing we could do is let HTML take a dependency on storage key's origin concept to replace the need to initialize sourceOrigin, but I think this is fine, modulo nit.