Ensure watermarked signed bundles don't allow user ID transfer

@MattMenke2 pointed out that if a server can get a large number of unique packages generated for two different origins (either by having signing keys for both origins or by getting those origins to cooperate), it can build a bundle that will transfer a user ID between those two origins, given our current idea of how bundle loading will work. That is:

1. When client C fetches https://evil.example/the_bundle, evil.example puts signed HTML files from the two origins into the bundle, each embedding a unique ID. (If the IDs are different, evil.example just records that they refer to the same user.) At this point, https://github.com/WICG/webpackage/blob/master/explainers/anti-tracking.md says evil.example doesn't have access to its own user ID, but this doesn't save us.
2. C redirects to origin1.example/index.html, which has access to both origin1.example's online storage and the embedded unique ID, so it reports that origin1.example's user ID is associated with the unique ID.
3. The user now navigates C to origin2.example/index.html. Our current notion of how bundles should work says that this doesn't go back to the network, since the user has already downloaded the content and shouldn't need to fetch it again. However, at this point, the new page has access to both origin2.example's online storage and the embedded unique ID, so it reports that association, and learns that origin2's user ID is associated with origin 1's user ID.∎

The simplest fix is to remove the ability to include multiple signed top-level origins in the same bundle. Or, similarly, declare that the top-level origin of the entire bundle is the one identified in its start URL, so no other origins within the bundle can access their online storage.

A requirement that signatures are X minutes old, as suggested in #422, doesn't help here, since evil.example can just stockpile unique IDs for that long.

If we can find a way to identify the a large number of different resources are available at the same URL, we could use that mechanism to re-allow multiple top-level resources.

Start with the anti-tracking.md explainer linked in the issue and review the bundle-loading assumptions described there. Determine whether bundles must allow multiple signed top-level origins, whether the bundle start URL should define the sole top-level origin, or whether resource identity can safely distinguish equivalent URLs; done means the user-ID transfer path is prevented by a documented design decision.