[css-images] Add a way to indicate that a CSS image should be decoded asynchronously

[smfr]

Similarly to how we're adding a way for authors to specify that content images should be able to be decoded asynchronously by the UA (whatwg/html#1920), we should add a way for authors to say that CSS images can be decoded async.

Async decoding here implies that there may be frames rendered after the time that the "load" event for an Image with the same URL as the CSS image in which the image does not appear.

This would probably be some kind of new argument to the image() function.

[tabatkins]

Yeah, sounds reasonable to me. The first part of the image() function is already accepting some keywords, it's easy to cram more in there.

[Crissov]

If it makes sense for HTML, it also makes sense for CSS.

For HTML content images, the assumption for default behavior is that they are important and should be decoded synchronously. For CSS styling images, the opposite assumption should be true, i.e. default to asynchronous decoding.

[Nadya678]

But data-urls in CSS should be decoded synchronously by default. They are embedded in CSS for this reason.

[gsnedders]

Related to #1088, which is about defining what blocks the load event and what doesn't. (At the moment, per spec, CSS images can be decoded async because the spec says nothing about what blocks the load event; I believe Edge doesn't block the load event on images in CSS.)

[AmeliaBR]

See related issues #1603 (crossorigin images) and #2994 (preloading images).

[emilio]

I think FF does mostly async image decoding by default? @tnikkel may be able to correct me though.