Support "global replacers" that change vanilla head parts (VHR, SUEMR, etc.) about easymod HOT 3 OPEN

This is still high priority but I'm going to remove it from the beta milestone and attempt it as a fast-follow. It's a little too ambitious a feature to develop and release without a few dedicated testers.

from easymod.

Ref #64 as there is some relation.

from easymod.

Some notes from a recent conversion in the chat:

• The biggest risk of creating broken facegens comes from head part replacers that change vertices. Changing anything else is fairly safe, but mismatched geometry will create clipping or seams or other moderate-to-severe issues.
• VHR disables morphs completely (deletes the Part subrecords/tri files), and other mods like High Poly Vanilla Hair seem to include morphs with all the sliders removed. Hair appears to be a special case where we shouldn't really need to worry about vertices because hair doesn't transform. Even in vanilla, the only slider that actually gets used seems to be the weight slider.
• Many "head part replacer" mods don't really change the geometry, they change some other safer aspect like the UVs (which are independent of vertices), texture paths, emissive properties, etc. These could be identified by having the same vertices as the vanilla mesh they're replacing. It's not necessary to inspect every facegen to do this check, only the head part mesh itself. In these cases, it would be possible to "diff" the head parts, similar to how we "diff" records, and apply the changes to the final facegen.
• For replacers that do not have vanilla geometry, it would be required to replace the entire sub-mesh in the facegen, and possibly disable other incompatible replacers. However, we can only do this if the replacer's geometry truly matches what's in the facegen, and the only way I can think of to do this right now is to read the morph/tri file (which priority?) and NPC sliders from the overhaul's record, try applying those sliders to the to the morph, and see if the vertices in the facegen are equal to the result. If so, then the new head part can be re-morphed and injected; otherwise, we have to skip it because the real source may actually be totally unknown.
• Pandorable's Elisif was given as an example of this. It appears to use one of the vanilla eyes, and maintain the vanilla sliders, but is actually totally different. There is no possible algorithmic way to know which eye mesh was really used, and it may have been completely custom. Thus it is not safe to just look at the head part name - when getting ready to replace an entire head part, it is absolutely required to do this (probably expensive) sanity check.

I haven't yet decided on how to structure the diffs, but I think it should be more than just a simple "copy everything from winning override". There are texture paths (which may come from the mesh itself, but also from alternate textures and/or TXST overrides in the plugin), all sorts of flags, special attributes like emissivity (e.g. #82 vampire eyes), specular and reflection attributes, UVs, alpha properties, and more. There aren't likely to be a ton of conflicting-but-compatible head part replacers, so it's not good to get overly complicated here, but the design has to at least maintain the principle of separation if and when they come into play.

Also, diffs in this case, unlike record diffs, may need to be structured as real diffs, i.e. "change value X to Y" and not just "change the value to Y". That way, if we encounter facegens that have already changed X to Z, we don't overwrite the change. This is especially likely to be the case for textures, but even things like UVs may have been customized.

The UI is going to need to report on what sorts of changes each global replacer makes, and give the option of whether or not to try to apply it to all NPCs, and maybe also rearrange their priority, although it is probably OK to just report the priority from in the load order. Without wanting to give too many hard-to-understand options, it may help to add one that allows overriding with new attributes even if the old attributes were changed from vanilla, e.g. the ability to say "yes, another mod might have messed with the emissive color, but we always want to remove glow".

from easymod.