More production-ready production build #987

Feature request: that the production build option produce output that follows many fairly easy "best practices":

• Concatenate all of the polyfills together, into a file named with a hash of the contents. Every round-trip counts.
• Ship the application plus the tree shaken libraries in another JS file (already working) again named based on a hash of the contents.
• Assume that those JS asset files will be permacached - hence the need to name them with a hash, because once a file is shipped it can never be changed under a permacache scheme.
• Inject the name of these two JavaScript files into the index, rather than the considerably more than 2 we get today even with the -prod option.
• If the poly-fill file isn't very large, consider combining it with the application and libraries to one JS file total. It is a competitive world, and the other folks can ship their whole thing with a single round trip, we can too.
• Generate .gz pre-gzipped files also.
• Offer an option that omits the main libraries (Angular!) from its own output and instead references a well-known CDN - this is sometimes a better approach for widely web deployed software, even though it loses the tree shaking. It would be slick to have this as a simple option while building instead of something to configure oneself.

Something generally like the above (details vary expert by expert) would be a solid baseline for every Angular developer to have immediately available in the CLI. A high percentage of Angular projects may then need no build tooling at all beyond the CLI.

(Something I would love to see, but it's probably a crazy amount of scope: automatically use "universal" to generate HTML for the first screen, then "CSS shake" to get the minimum CSS for this first screen, and include both of the above directly in the HTML, therefore providing a very high score for "Google page speed" for Angular apps managed using the CLI. This would be bliss. I am just dreaming, not requesting this feature...)