Made enough progress on #5842 's research system work that it's probably worth having an issue set up. And hopefully, this time I've not munged the hell out of the git commit history.

Progress so far:

• Built separate jsons for each existing research unit, including More Scrolls.
• Json parsing has moved into GlobalResearch.java as a separate constructor class. I've left the code-side one, so other modders can add from their code rather than having to use jsons.
• Moved a lot of research-related static strings into ResearchConstants, and tried to give a reasonable order to them, and updated the references to match. Mostly affects the hut unlocks and enhanced gates, but if someone wants to be able to make a research effect for them from a different mod, it's all in the api rather than coremod now.
• Removed ResearchInitializer and most of the research-cost-related config file stuff. Those'll still exist in older config files, but simplifies a lot.
• Handles removal of world-specific datapack research items from worlds without that datapack enabled.
• Set up a ResearchEffectRegistry. It's not a genuine ForgeRegistry, since (currently all!) entries that won't show up until long after compile-time, but I'm hoping it's modeled correctly and has the javadocs necessary to point people where they need to look to implement research from code. Right now it's a registry of IResearchEffects types by their first example; eventually that will change to include all IResearchEffects. Returns collections of effects by identifier, now. Up to the other coder to sort them, but likely to see varied enough behavior that a built-in sorted type doesn't make sense.

It's in better shape, but still with some limitations :

• There's a lot of typo cleanup (tickshot, whirldwind, so forth) and a small amount of it may cause mismatches when loading from NBT. I can revert that fairly quickly, or put a helper in the nbt loader to translate from the old version, depending on preference. Separated by /// region, so hopefully clear enough to remove when it's no longer useful.
• I've had no luck finding a datapack unload event. Because datapacks are loaded during every world load, and any world with a custom datapack can theoretically have events that aren't present in other worlds (only relevant for recipes right now), the datapack-based ones should be cleared out between world loads. I'd like to eventually handle this dynamically.
• But I can't just wipe the entire registry, because other mods might only init ResearchEffects once. So that's got a hacky workaround. May also apply to a few other datapack loader situations (block tags, for example). Really far edge case, but obnoxious enough that it's worth considering -- I can see modpack makers doing it when trying to debug their jsons. Not seeing any good fix for someone disabling a datapack by command.
• There's more error checking, but badly enough created research jsons will cause crashes during world load, mostly type mismatches. The gson documentation just suggests throwing everything into a big try/catch, and it might just come to that, but I'm open to better suggestions. Nearly as the point of running getJsonPrimitive and instanceofing everything.
• Haven't done much on translations.
• There's still a lot of static strings, even if they're all in one place. UnlockAbility, Multiplier, and Addition effects that's probably not going to go away. I think it's possible to dynamically handle the unlockBuilding cases, though, and the ResearchRegistry has some helper methods and caching to work toward that if it makes sense to explore. But researchEffectManager is a fairly elegant option as is, and I don't want to start revamping every hut if you all like things they way they are.
• Didn't touch the rendering side of the University Research UI, beyond letting it read multiple requirements/effects at all.

There's probably a few other behaviors I'm missing. So far, it's loaded, run through progress, and handled a pre-existing colony with little issue beyond the above, both locally and as LAN server. Not sure if that's enough to go to a Draft Pull, or if it needs more consideration first. Definitely at the point where it could use another set of eyes.