Slightly refactor/fix/change/improve WebP config

[goodusername123]

PluginWebP.cpp has a fundamentally flawed understanding of how the config value "quality" interacts with lossless encoding in libwebp and this commit solves that along with some other minor changes.

the method and "quality" values in this pull request equate to -z 5 (was -z 3 in this pull request originally) in cwebp/libwebp (the default is -z 6 which is lower then FreeImage's default). for more information see these links:
https://developers.google.com/speed/webp/docs/cwebp
https://github.com/webmproject/libwebp/blob/874069042ead095f8a8d6bdd35b9b145ce80af43/src/enc/config_enc.c#L136

If the encoding ends up being considered too slow then simply change the values to a lower preset as defined in the second URL I linked (you can technically set them to whatever but it's cleaner to have them just match one of the -z presets)

[jonnyawsom3]

To be specific, the method 6 quality 100 config created during the fork of this repository activated WebP's Lossless Cruncher. Which brute force encodes the image on (up to) 2 threads to find the smallest size (no wonder there were performance regressions).

I remember doing tests to find the best speed:density:memory ratio between method and quality settings, but apparently I never posted my findings or I've lost them since. I'll keep looking and see if I can find them again

[jonnyawsom3]

Did some tests, method 1 quality 20 is 10% smaller and 25% faster. method 0 quality 0 is 1% larger and 86% faster

For lossy, method 5 is 46% slower but 64% smaller, so probably worth it. Speed doesn't change much but anything other than method 0 is less than half the size. Could also add SharpYUV to avoid desaturated colours

So I'd suggest method 1 quality 20 for lossless and method 5 SharpYUV for lossy

[goodusername123]

To be specific, the method 6 quality 100 config created during the fork of this repository activated WebP's Lossless Cruncher. Which brute force encodes the image on (up to) 2 threads to find the smallest size (no wonder there were performance regressions).

I remember doing tests to find the best speed:density:memory ratio between method and quality settings, but apparently I never posted my findings or I've lost them since. I'll keep looking and see if I can find them again

I just went and checked the non-fork version of FreeImage and it seems like for lossless it was ending up getting encoded with quality 75 (the default because it wasn't changed) and method 6 which is presumably what the before/"old" speeds in Yellow-Dog-Man/Resonite-Issues#874 are

Did some tests, method 1 quality 20 is 10% smaller and 25% faster. method 0 quality 0 is 1% larger and 86% faster

For lossy, method 5 is 46% slower but 64% smaller, so probably worth it. Speed doesn't change much but anything other than method 0 is less than half the size. Could also add SharpYUV to avoid desaturated colours

So I'd suggest method 1 quality 20 for lossless and method 5 SharpYUV for lossy

compared to method 3 and quality 30 lossless? if so then the smaller size you are getting is weird but to be fair I haven't done much testing myself between encoding combinations although I feel a bit iffy about going so low with the lossless effort especially since the complaints about speed only came from the lossless cruncher being enabled originally so I feel like anything that either matches or is a tiny bit below FreeImage's original settings of method 6 quality 75/unset might be the way to go so I'm thinking that maybe raising the effort I selected rather then lowing it might be the better option.
As for SharpYUV yeah I could probably add it since unlike auto-filter it's not considered "experimental" and is it's own project which means that it actually gets work done on it to make it not as slow.

[jonnyawsom3]

Discussing on Discord.

[goodusername123]

After some short discussion outside of GitHub clearing up some confusion (such as me not understanding what the above results where comparing against) I feel like this pull request is ready to be reviewed/merged.