Allow custom cursor caching

[daxpedda]

This is a proposal to change the API as discussed before in IRC and #3218.
The API now works like this:

let custom_cursor = CustomCursor::from_rgba(rgba, width, height, hotspot_x, hotspot_y)
    .unwrap()
    .build(&event_loop);
window.set_custom_cursor(&custom_cursor);

So now building a CustomCursor requires access to EventLoopWindowTarget, the cursor itself remains Send + Sync (the builder itself as well).

All backends work exactly the same as before, ergo they don't implement caching. I only implemented caching for Web.
I will make follow-up PRs for Windows and MacOS, where I know caching should be pretty straightforward and uncontroversial to implement.

I also made a big improvement in the Web implementation: we now wait for cursors to actually load before applying them. We had a really complex fallback cursor system in place beforehand.

Cc @kchibisov, @eero-lehtinen.

[notgull]

LGTM to me for X11 changes

[eero-lehtinen]

Looks really nice and just like we talked about. Also implementing this shouldn't be too hard for x11 and wayland anymore because both of their cursor types already do cleanup with Drop. Wayland's SlotPool does the hard work for us.

[daxpedda]

To summarize what I did for Web here because this was ridiculously complicated:

Before

1. Used the object or user-supplied URL.
2. URL still had to be loaded, even if we created the image and stored it as an object URL.
3. During loading time the cursor switched back to the previous cursor, which we added as a fallback.

Unfortunately this isn't ideal, as we also didn't determine if the previous cursor has finished loading. It also complicated the code, storing and account for previous cursors.

After

1. Loaded the object or user-supplied URL into an HTMLImageElement and waited for it to finish decoding.
2. Store the HTMLImageElement to prevent the browser from cleaning up the newly decoded image.

This simplified the code a lot, but we also had to add a lot more code to handle all this correctly. Specifically the fact that HTMLImageElement can't be successfully dropped in another thread, so when we detect that we aren't on the main thread we send the HTMLImageElement to it to be cleaned up.

[madsmtm]

API looks fine to me