Support use case: using web package for H2-style JS bundles

Reflecting on H2 push is tougher than I thought, there's still one common use case: a set of JS binaries are always downloaded together. This would typically be due to breaking down a big binary into smaller ones where:

1. The first binary is critical for immediate execution.
2. All other binaries could be delayed. But ideally not turned into a download waterfall.
3. Otherwise, the "other" binaries are never used by themselves, without the first binary.

This is one case, where H2 push would be useful and Web Packages could make this a much simpler and more predictable.

To further explain this, consider one big binary that looks like this:

// First critical block of JS.
(function() {
  global.doLater = function() {...};
  // E.g. 20K of JS code.
})();

// Second non-critical block of JS.
doLater(function() {
  // E.g. 40K of JS code.
});

// Third non-critical block of JS.
doLater(function() {
  // E.g. 60K of JS code.
});

This kind of delivery could still save lots of CPU by not immediately executing block 2 and 3, but the main negative is that the overall binary is bigger and has to be fully parsed/compiled before anything can be executed, thus delaying execution of the critical block 1. While some engines are capable of lazy compiling some of the non-critical blocks, the full download/parse is still necessary.

Web Packages could help this case by splitting a big binary into smaller files and executing the smaller critical blocks as soon as they are downloaded/parsed.

/cc @cramforce

No repository file, test, or entry point is named. Start by reading the linked “H2 push is tougher than I thought” article and the Web Packages implementation context, then determine how this bundled-JavaScript use case should be specified and what tests would demonstrate support.