Discussion: Creating a light version of the runtime for transformed documents

When using the AMP toolbox optimizer, we should be able to tell when certain parts of the runtime are not necessary for a given page. We could consider making a lightweight runtime with a smaller set of code that handles a large percentage of pages, and a full one including all the features.

One example of feature not often needed for transformed pages is the client-side static layout logic ([`applyStaticLayout`](https://github.com/ampproject/amphtml/blob/77862fb19d2697734b22120ddf70edccf9b9afd8/src/layout.js#L330)) in layout.js along with the corresponding CSS in `ampshared.css`. Another example is some CSS needed for amp-accordion in `ampshared.css`.

This would need to be included for anything doing client-side rendering (`amp-list`, `amp-mustache`, `amp-script`), but may be omitted for some number of more simple pages.

Some things can also have a lightweight stub implementation in the lightweight version, without breaking the synchronous nature of their heavyweight implementations. For example, `url-replacements-impl.js`, `viewer-impl.js`, `pull-to-refresh.js` (only needed if in a viewer), `font-stylesheet-timeout` (only needed if using a custom font), `document-submit` (only needed if amp-form is present).

We could potentially create a variety of binaries, but I think to keep things simple, we could create just two variants. The criteria for which features to include/exclude from the light binary are not exactly clear, there is a trade-off between having more pages with the light binary vs having a smaller light binary.

Using [source-map-explorer](https://www.npmjs.com/package/source-map-explorer) to get a sense of code size, combined with a survey of existing pages and what features are commonly used could be a good way to prioritize which features to include/exclude.