Move CSS/JS preprocessing to a View listener

Blocked by #2334029: Add js/css/libraries/head links to HTML fragments and pass it along to the page.

Problem/Motivation

CSS and JS aggregation and preprocessing still happens internally to _drupal_get_css() and company. That's a legacy of the old page building model.

Instead, we have this great new model where everything is an HtmlFragment or HtmlPage, and we can use View listeners to modify the HtmlPage object directly almost like an alter hook. That's exactly where we can/should be doing CSS/JS preprocessing. But... we're not.

Proposed resolution

So, let's do that.

* Add a view subscriber that runs after fragment->page conversion but before page->response conversion.
* That view subscriber should extract the CSS/JS from the Page object and run it through the existing mangling optimizer services (CssOptimizer and JsOptimizer), then put the result back on the Page object. (This may be easiest to do by creating a new page object and transferring everything over. Implementation detail.)
* HtmlPage's getScripts() and getStyles() should be modified to NOT call drupal_get_css()/drupal_get_js(). That presumes that we've eliminated any CSS/JS sent to them by instead putting them onto HtmlFragments, as described in the blocking issue. Those methods should work the same way as the other head element pieces.

Note: This says nothing about using Assetic (#1762204: Introduce Assetic compatibility layer for core's internal handling of assets). At this point I think that is over-aggressive. The scope of this issue is just to rearrange where the asset mangling happens in the pipeline. It does not replace the current asset mangling logic, which can stay essentially the same give or take necessary tweaks to the interfaces to use the new pipeline. However, it then becomes quite simple to drop one listener and replace it with another that uses some other strategy, including none at all if one is on an HTTP 2 server.

Remaining tasks

User interface changes

None.

API changes

In practice, probably fairly little. Only people writing alternate CSS/JS preprocessors would care.