Move HTTP requests out of image cache logic

[jdm]

The cache should be a simple store for decoded pixels with a key that can distinguish between two image requests for the same URL that included different sets of cookies, for example. The (eventual) network cache should be in charge of caching the original response bytes to facilitate re-decoding if necessary.

This work will also enable much easier implementation of image elements blocking the document's load event.

[jdm]

Current effort exists in #11453.

[KiChjang]

I'm looking for something to kill some time, and this looks like a good thing to do so

[jdm]

We should chat about the problems I ran up against.

[KiChjang]

There's at least a rebased version of #11453 located here.

[jdm]

So as not to leave you hanging, these were the Hard Problems that I realized:

• https://groups.google.com/d/msg/mozilla.dev.servo/kxgpmsuDw_s/_BtBVW7bPAAJ
• for images that are loaded based on CSS (eg. background-image), it is much more difficult (and more code-duplication-y) to respect things like the document's referrer policy since we're in the layout thread. It would be so nice if we could somehow make the image load originate from the script thread instead, but I don't have a clear idea of how to make this happen (handwave: somehow return a list of image URLs and originating loads from layout to script, make script deal with them)

I think those are the only two that I got stuck on.

[KiChjang]

Both problems sound like they can be solved with futures-rs, though that crate only provides a trait for Futures, and we'll need to work on the implementation on how exactly futures get resolved by the script thread.