pdb_ng2: Bundling strategy

[mrjmd]

Especially with the release of RC1 for Angular 2, our request numbers are out of control. Now that we have a basic update in place, we need to get some bundling going on to reduce our requests.

Since we can't know in advance which components will be on a specific page, we're going to rely on a base bundle of core assets. Per-component bundling will come after that.

Also offline template compiling should be incorporated into overall bundling strategy.

The ultimate goal would be to get in place a bundling strategy that for any given page will strike the appropriate balance between cacheability and reusability.

[mrjmd]

My stopgap measure for upgrading to the RC's was to rely on the umd.js packages provided by npm. I'm doing this for all the ng2 packages as well as rxjs... but this is obviously not an ideal solution. For now it's keeping the request numbers down and is better than the full front loading of the framework we were doing with ng2 betas, at least.

I've done a lot of thinking about this but it is a pretty hard problem. Bundling appropriately is complicated by the fact that which components will appear on any given page is dynamically driven by which blocks are placed via the UI.

I was recently pointed to the System bundlers trace API (https://github.com/systemjs/builder#example---direct-trace-api), which gives us a lot more control over how we determine joint dependencies between components.

I've been thinking about a recursive version of trace API, where we first create component bundles, and then page bundles, and then vendor / app bundles. Having bundle generation triggered by block placement regardless of placement UI (core blocks, panels, etc) is no easy task, and may force a node.js requirement on the production box, as well.