Config-driven PAW items customization

[gotmachine]

The current PAWStockGroups patch could be improved in some ways :

• The way this currently works, we apply the groups on every part / module instantiation, which is far from optimal from a performance / overhead standpoint. We should look into patching the cached ReflectedData instead.
• Many people have expressed the need to customize the behavior of the patch, usually because they don't like having to go through the extra step of expanding/collapsing groups for specific items. The main complaint I remember seeing is about the part level autostrut toggle.

Some tangentially related considerations :

• Some modders are using the B9PS ModuleB9AssignUiGroups to customize the PAW group of foreign modules. This B9PS module allow to set the PAW group for all PAW items of a target module on the same part. B9PS only set the group if none is already assigned, so it doesn't work for modules KSPCF is already targeting. On a side note, this B9PS feature isn't great from a performance PoV, both because of the module spam and (as usual) because B9PS loading infrastructure is the incarnation of clean code principles gone wrong.
• There is a module currently part of BDB whose purpose is to set actions UI titles and default action group on foreign modules. @SofieBrink has expressed the desire to replace that with a more generalized solution also allowing changing the UI name of fields/events of foreign modules.

The common point between all those features is that the required underlying infrastructure is essentially the same, so it would make sense to have an unified solution. The general idea would be a config-driven way to override/define paw groups and to alter fields/events/action names :

• At a global level for every part and module of a given type, with top-level configs, and through altering the stock ReflectedData.
• At a per-part, per-module level for fields/events/actions, overriding the global level modifications. The customization would be defined directly in the target part/module config as an extra node, parsed at part compilation time (likely in a AvailablePart ParsePart(UrlDir.UrlConfig urlConfig, ConfigNode node) postfix) and stored in a static database (likely a dictionary with AvailablePart keys), which would then be queried and applied in a Part.Start() prefix (as we need to wait for the part and every module to go through its ModularSetup() from its Awake()).

One drawback to the config-driven approach is that we loose the ability to implement some code-based refinements. Notably, we currently set the default expanded/collapsed state of our custom groups depending on the module count (which isn't that great of an heuristic). We also do some module parsing to generate/customize the generators PAW group title.

Also, making things config driven, while allowing full customization, isn't really addressing the general UX issue for people that want some parts of the KSPCF PAW customization but not others, as this require some basic understanding of MM patching, and so is far from user friendly. This might end up being a problem, as it is likely people will be disabling the whole patch, which isn't desirable if we implement modding features other mods start relying upon. Likely can be solved by clearly decoupling the code patch from the default configs in separate feature switches.

And on a side note, it might be worthwhile to implement the base infrastructure for this in a generalized way with a public API that other plugins could leverage. Something like PartInstanceModification and ModuleInstanceModification base classes, with a constructor receiving the part/module prefab and config as arguments, called during part compilation, then virtual OnPartInstantiated() / OnModuleInstantiated() methods called before Part.Start(). This would allow other KSPCF patches and any plugin to implement custom logic to alter fields/events/actions, and could possibly have other use cases as well.