Storage-based cover caching

[OxygenCobalt]

Spun off from #104. More or less, Auxio could switch from it's current on-demand album cover system to a storage-cached album cover system. Images found when loading the library will be put into app storage and then retrieved whenever needed. This is already technically done by MediaStore, but with #322 jeopardizing access to their image cache (plus the generally garbage state of it's image cache), I'll likely need to build this myself.

The covers stored would be something like 1000x1000 (probably lower) in a currently undecided format. PNG will not be used since it's too bulky, and JPEG will not be used since it's terrible.

This has a few hypothetical benefits:

• Currently regarding #37, there is no way I can integrate a memcache implementation (like Coil) into the library metadata I have to send. This would force me to use lower-quality images for the library shown in Android Auto. If I send a link to a storage-cached image however, that issue is resolved.
• Similarly, loading covers on the fly is really not what I should be doing for the playback notification. I should actually be sending a link to an online or on-device image file. This results in the notification freezing up when it has to load huge cover art. Again, using a link will work.
• Speaking of huge cover art, given the arbitrary data that #104 would allow Auxio to encounter, there needs to be some way to downscale very large cover art as soon as possible to prevent an OOM. This is best if it was not done repeatedly in-memory and thus storage caching would be more ideal.

Possible drawbacks:

• This does risk making the app take up a good amount more space. Albeit, the devices that would suffer from this are also the ones that suffer from poor memory limits that the current system doesn't play nicely with, so it doesn't matter too much I'd imagine.

[mintydev789]

Please just don't make this reuse one album cover for all songs with missing covers. I've seen multiple music players that do this and it's very annoying.

[OxygenCobalt]

That won't be the case @dmint789. I'm not even sure how people end up end up designing a cover system that works like that.

[OxygenCobalt]

De-prioritizing since it's not needed.

[OxygenCobalt]

Mild tweak to this: Instead of maintaining a storage cache with the music loader, instead dynamically populate it. Cover art is loaded, keyed, and then reused with the key to save memory ideally. Then I just tag them all with timestamps to make sure that they stay fresh. More costly in the first pass, but much easier to work with and isolate. It also allows me to eliminate image loading from the main music loader, which is causing a huge slowdown #802.