Adding JS/CSS assets in AJAX responses requires 'unsafe-inline' Content Security Policy

I'm uncertain if the distinction between header and footer JS assets is necessary in AJAX responses. My assumption is that all JS from the original page is already parsed before any AJAX requests are sent, so only the relative order of the new files matters, and appending them all to the end of the body tag would have the same affect as placing the header scripts in the page head.
No page scripts can be dependent on the new files required from an AJAX request (otherwise they would have already been include on the initial page), so it shouldn't be breaking to move them to the footer.

Here's a quick patch to test the concept. One current limitation is that asset attributes (e.g. media for stylesheets) are not included in the data sent in the response.

I tested this by editing the "Featured Articles" view of the Umami profile. Before the patch, adding views.module.css (stable), node.css (classy), and picturefill.min.js are all blocked by Content Security Policy when loading the preview.
With the patch, the corresponding HTML elements are added to the page (verifiable in the inspector), the network requests are not blocked, and the picturefill library is available in the browser console.

This patch adds deprecation notices, any additional attributes set for an asset file (e.g. css media, js async), and the cache-buster query parameter when needed.

I set the deprecation notice to 9.0.0, as my understanding is that no new deprecations can be added in 8.9, and I'm not sure if this can be added in a 8.8 patch release?

Saw some "CKEDITOR is not defined" errors while testing this:

https://www.html5rocks.com/en/tutorials/speed/script-loading/

Scripts that are dynamically created and added to the document are async by default, they don’t block rendering and execute as soon as they download, meaning they could come out in the wrong order. However, we can explicitly mark them as not async:

[
  '//other-domain.com/1.js',
  '2.js'
].forEach(function(src) {
  var script = document.createElement('script');
  script.src = src;
  script.async = false;
  document.head.appendChild(script);
});

There's a TODO in the patch regarding support for the browser attribute of library assets. The conditional comments that the feature makes use of are unsupported in IE10+, and Drupal now only supports IE11.
#3095113: Deprecate IE conditional comments support

If an asset has any browser conditions set, it could just be omitted from the AJAX response's assets.

I ran one of the failing tests locally and it passed, so I'm not sure if this change introduces a timing issue since it's not blocking rendering in the same way as before.

Removal of 'browsers' was postponed to 10.0 (with deprecation in 9.1).

\Drupal\Core\Ajax\AddCssCommand was introduced for IE <= 9, because they didn't support @import statements if they were in a PrependCommand.

Drupal 8 no longer uses @import statements (#2897408: Remove IE9 support from CssCollectionRenderer and provide it in contrib instead), and has now also removed the IE9 support code from AddCssCommand (#3100147: Remove @import parsing from Drupal.AjaxCommands.prototype.add_css), so AddCssCommand could be deprecated (in 9.1), and removed (in 10.0) separately from this issue.

#3110517: Improve Drupal\Core\Ajax\AddCssCommand to accept an array of CSS assets

Content Security Policy added a submodule to override core to use this approach #3166840: Override core's handling of library assets in AJAX responses

Some refactoring was done that should be ported to this patch.

This will be resolved by these two issues:
#1988968: Drupal.ajax does not guarantee that "add new JS file to page" commands have finished before calling said JS
#3110517: Improve Drupal\Core\Ajax\AddCssCommand to accept an array of CSS assets