Image reading backend refactor

[DavidLokison]

Following #276, we need to refactor the backend selection to use the selected backend for both MD3 and Base16 color palette generation. The easiest way to do this would probably be to make a collection of material_color's DynamicColor like in MaterialDynamicColors to select each of the Base16 colors out of the already generated DynamicScheme.

[Mikilio]

A few months ago I came upon this same issue and tried to do a refactor. I decided to delay that at least until this is closed. Aiving/material-colors#33

I was once working on a color generation scheme for base16 and wanted to upstream it to matugen. But I then saw that there seems to be quite a lot of unused code and bad coupling of usually independent functionality.

I was going to use the source color palette for base00-08 and add the accent colors as custom color palletes. However, even a change like that is unnecessarily hard and inefficient without a major refactor (the expensive clustering needs to be run twice per color generation scheme even though once would suffice in theory). Not to mention that after the update of https://github.com/Aiving/material-colors/ many parts of the code will become massively incompatible as ARGB will not be the reference color format anymore (matugen has a lot of "unnecessary" code for color conversion)

Once the above issue is resolved and there is a new release I can offer to rewrite the color scheme generation and caching part of matugen in a way that is compatible with the templates, since I already started working on that.

[InioX]

I already got matugen to work with the latest git version of material-colors, it's on a separate branch. I removed some stuff for now that I'll add back later. Really not proud of the cache workaround but at that time Argb didn't implement Deserialize. https://github.com/InioX/matugen/tree/material-lib-testing

I started this project 3 years ago when I was learning rust and I just kept on adding code since then, I didn't really think about the structure that much. I really want to separate the md3 stuff into its own folder like base16.

After I'm done with the refactoring of that, I want to separate the engine and make it into its own library but that might be hard because it depends on a lot of color formatting stuff from matugen.

[Mikilio]

It's nice to see that you are very active in this project loved by many and have started the refactoring. Thank you very much!

Some advice I'd like to share:

I really want to separate the md3 stuff into its own folder like base16.

If you really want to separate it like that then you should additionally abstract the theme color extraction and let it be consumed by both base16 and md3. Currently, both modules would build a theme only based on the source color but base 16 for example could really benefit from also preserving the original quantizing results.
The custom code for k-clustering is likely redundant to the optimized k-clustering algorithm already provided by md3.

My original objective in getting involved with matugen was to improve the base16 scheme generation. After the refactoring that should be much easier.

[InioX]

Thanks a lot for your kind words :D

I already put most of the md3 stuff where it should be, and I'll work on the quantization stuff next. I also separated the templating engine from matugen, so you should be able to use it on its own now.