Offer specific differences in case of sprite group palette errors

[PhoenixBound]

Palette errors are common when working with NPC sprites in CoilSnake for the first time. Sometimes new users save a sprite in full color instead of indexed color (or their image editor has no option to do otherwise). Sometimes they leave colors out of the palette that their sprite doesn't use. Sometimes they mix up the order of the palette while trying to solve those other issues (or, again, because their image editor gives little control over the palette). Sometimes they copy colors from a screenshot in-game or an external sprite sheet, and the colors they're using are all off by like 3 or 4 in every channel, due to quirks of CoilSnake's color conversion logic or the in-game lighting applied to sprites or whatever else.

In all of those cases, CoilSnake does have existing error messages that explain the kind of problem, but they don't always tell the user what the solution to the problem might be, especially in cases where the image has a palette but it's not indexed. You just get an opaque Sprite group #xxx uses an invalid palette message. Even a more experienced CoilSnake user who isn't at a PC may miss instances of the "all colors are ever so slightly off" error when offering support, as happened today in the EarthBound Beginnings Remake's Discord server. It might be nice if this message could be improved by pointing out a specific color difference or missing color or color order change.

Proposed changes

• When the SpriteGroupModule fails to find an exact match for the palette of an image, it should attempt to "match" the sprite group's palette against the valid palettes by fuzzier means and find near-exact matches. I'm not sure what that involves, but it probably involves sorting the palette in some unambiguous total order and calculating the mean absolute error or mean squared error across all palettes. It should be designed with the most common kinds of errors (mentioned above) in mind.
  • Unsure how to account for colors being missing from the palette, though, or what the threshold for being a "close match" vs "not matching at all" should be.
  • Also unsure if any special prioritization is needed to choose between displaying "near matches of many/all colors" vs "exact match of fewer colors" for UX purposes, when there are many palettes.)
  • There should be some threshold for whether any matches get displayed. No one wants to read an 8+-line error message filled with a bunch of numbers if they can help it. But since some palettes are identical apart from a single color, like 5 and 6, showing multiple palettes will be necessary in some cases to avoid misleading the user.
  • It might be worthwhile to try excluding the transparent color of the vanilla palettes from matching, since it will often be flushed to #000000 in bad PNGs and that's a fair distance away from the actually used colors like #00B080 in vanilla. I dunno though.
• After finding a match, it should explain why it's not an exact match.
  • If all the colors in the PNG match a palette exactly, it should give a specific example of a color being missing or reordered. (This could just be "Color X in sprite_group_palettes.yml palette 5: #YYYYYY Color X in Z.png: #AAAAAA" showing an unrelated color.)
  • If it's a close match, it should give a specific example of a different color between the two palettes.

Other notes

This issue proposes something that's firmly in the realm of heuristics and trying to guess user intent, which isn't good. If we guess wrong, then the error message may lead to a worse user experience. I'm not a fan of needing to guess the palette like this in the first place. So many other aspects of sprite groups require edits to sprite_groups.yml, like their "size," that it feels like something you could turn into a more uniform set of warnings that don't halt compilation instead, similar to how title screen stuff is currently handled. But I'm not writing any more paragraphs about that.