Improve support for child overhauls and race edits

[focustense]

Children will be filtered out completely, as of #60, and some overhauls have problems because they change an NPC's race, or edit face geometry of vanilla races, etc. To bring all of this goodness back and make it simple again, what I think we can do is the following:

• Generate a list of all the expected head parts of an NPC, including those explicitly configured and those that are default for the race
• Generate a list of all the head part nodes in the facegen mesh, and see if they match
• If they don't match, first try to rename the ones that should match
  • i.e. if we are supposed to have MaleHeadNord and we get MaleHeadImperial, then change the name of the MaleHeadImperial node to MaleHeadNord without changing any of its contents
  • This is a cheat, it might not work at all and has to be tested. An example cited is Aringoth, for which USSEP changes the race and some overhauls don't inherit. Can use this one as a test bed, manually, before trying to code it.
  • If it does work, then it is likely the best thing to do, because replacing it with a new head part (including the actual mesh) could lose the sculpting and make it more vanilla-like.
  • We also need a way to detect the "old" head part, whether it is going to be deleted and replaced or just renamed. This could possibly be done by comparing the NIF node names to editor IDs of head parts in the load order - as long as we can find the old head part, we can figure out which one needs to be renamed.
• If renaming doesn't work, either because it's not viable with the game engine or because we simply can't find the old head part, then the alternative is to delete all facegen child nodes that aren't in the winning face record, and add any child nodes that are in the record but missing from the facegen. This will almost certainly change the appearance, and could act more like the "Face Discoloration Fix" in practice.

This is not too different from the work required for #6, and is in fact a more generalized implementation, albeit without the additional UI options needed for hair.

Parsing every single NIF to check for consistency could be painfully slow. I can profile it, just to be certain, but more likely we are going to need to use heuristic detection to find the NPCs that could have problems, and work from that, similar to #59 for build warnings.

[focustense]

Another, short-term fix that might work for simpler race edits is to actually forward race edits from overhaul plugins when the new race is already in one of the EasyNPC mod's masters (i.e. doesn't need to be copied), and either:

• The default plugin hasn't changed the race from vanilla, or is vanilla itself
• The overhaul actually depends on the default plugin, which implies that the mod author has already done what is necessary for compatibility. For example, Northbourne all depend on USSEP, therefore we can assume that if they change the race from USSEP, they aren't breaking anything (and if they do, it's a problem with their mod, not EasyNPC).

This is a much simpler and more narrowly-scoped fix that is not intended to cover all cases. Both RS Children and TKAA create new races, and include many non-visual edits as well. This is not meant for those, only meant for mods like "Jarls Re-Imagined" that e.g. change the race from Elder to Nord. NVICO was cited as well but the current version of NVICO doesn't actually have the reported change.

A more permissive rule could allow forwarding race edits as long as they are not reversions - i.e. don't change the race from the default plugin back to vanilla, but instead to some new/other race. However, this could be a minefield, as it is impossible to know whether the mod author already considered this, unless there is a direct master dependency as described earlier.

[focustense]

Rambling here, but...

One of the things I'm not sure about is if some of these mods actually should change the race. Changing from Elder to Nord seems like it might have been a cheap shortcut for textures, vs. providing new texture paths in the facegen or alternate textures in the record. What if the elder race was actually important? I'm not totally convinced that the author has considered all of the possible ramifications. Races do a lot more than just visuals, and mod authors using them solely for the purpose of messing with visuals may not be making safe changes.

This might really be a case where we need the end user to tick a box for the mod, saying "yes, I'm OK with this overhaul changing NPC races and don't think it will mess anything else up and don't care if it does". And would also relate to master reporting (#17) because, for something as large as race changes, I think we're better off keeping a dependency on the original for the race ref, at least until that landscape is better understood.

[focustense]

Another reported mod is "Disparity and Diversity" here (https://www.nexusmods.com/skyrimspecialedition/mods/43779).

It occurs to me that there may be a much simpler way to get overhauls to work alongside these mods, which is to simply make all overhauled NPC head parts explicit.

I didn't fully understand this until I wrote all the head-part inheritance code that's now in the develop branch, but the way this works in the game data is that NPC head parts are themselves just "override" for whatever the race's default head parts are. This is why race edits frequently cause blackface - because the NPC doesn't define every head part, only the ones that have actually changed. So something as trivial as a default hair or eyebrow change can break a mod using a custom face, and similarly, a mod that tries to change the default face for a race will break hair mods.

But if we simply write out the overhauled NPCs with their full list of head parts derived from their intended race (based on their actual masters), and not allow them to default to the whatever the race happens to be in their load order, then there is no conflict anymore. The facegens were designed for specific head parts and those are the head parts we should use.

Another choice is to read the expected head parts from the facegen NIF instead, if it's available. This could possibly be more reliable - but not much more, and likely a whole lot slower. Last resort only.

[focustense]

A new mod, Uniquely Human Project, appears to function as a kind of global replacer, essentially adding new body types by adding new races. Could potentially try to incorporate mods like this by treating them as global replacers - seems like the mod is mainly just a shortcut to introduce new WNAMs. This might cause seams, but would need to test either way.