Datagen everything that can be

[GizmoTheMoonPig]

This is an updated version of my previous PR #796.

Changes in this PR:

• migrates the remaining blockstate and simple block model files to datagen
• creates a data generator for the English language file
• creates a data generator for all FD sound definitions
• moves all loot modifiers and tables to datagen
• moves vanilla conditional recipes to datagen
• moves all datapack registry related files to datagen (configured/placed features, damage types, and biome modifiers)
• datagens the pack.mcmeta file (you'll be able to remove this file entirely in future versions!)
• removes unneeded sign atlas Json. Since you use the entity/signs directory for your signs already, vanilla covers this for you.
• changes one single subtitle key to allow for easier datagen (farmersdelight.subtitles.tomato.pick -> farmersdelight.subtitles.tomato_bush.pick_tomatoes). I went ahead and updated the key in all the translations the mod has as well.
• add a tag for blocks wild tomato plants can grow on. This was previously a list in the feature that couldn't be changed without a datapack replacing the whole feature, so I figured a tag would be a good idea for it. I think moving all the features to use a tag would be a smart idea, but ultimately up to you.

---

You may notice there's still quite a few files in the data and assets folder that could potentially be moved to datagen. Here's my reasoning for not:

• remaining block/item models: all files left in here have custom transformations and/or models. While you can replicate these in datagen its honestly not worth it, so I left those alone.
• all compat related things: since things like Create's recipes would need you to write a custom Json builder for those recipes, I decided it's probably better to keep those handwritten and just focus on Minecraft/FD related things being datagenned. I don't know if the various mods you support have datagen support regardless and having more dependencies in your workspace makes porting to future versions a bit more tedious, so the cons outweigh the pros for this.

Future things to do:

• Move particle descriptions to datagen. This is technically already doable with a bump in the forge version (47.1.8 minimum) but if you don't want to do that I understand. I can come back in a later version and do that for you if you wish.
• Enchantment datagen. 1.21 moves enchantments to be a datapack registry and it's probably wise to datagen it similar to how the damage type is done. Again, happy to do this for you in the future.

---

If anything isn't to your liking, please let me know and I will fix it. Thank you!

[vectorwing]

Hi! Sorry for delaying my review... things have been rough regarding my drive to work on the mod this past year, and I ended up on a long hiatus again.

First off, thanks for making this a datagen-only PR, as per my previous request! The sheer volume of changes intimidated me at first, especially since datagen requires me to learn how each thing works so I can maintain it.

I am currently making an effort to zero out all PR's and issues for the 1.3 update, so I can look into this one fully now, if you're still available to update it. If not, that's also fine, and I apologize again for my delay. 🙏

[vectorwing]

I think I prefer not datagenning the en_us lang.

Looking at the output, it sorts every lang in alphabetical order, while I prefer sorting them through arbitrary groups to make it more human-readable for translators, especially since we don't have a translation tool such as Crowdin.

Since langs are a very manually-updated thing, it being separate from the others also makes things a bit harder to maintain. I update pt_br and en_pt by hand as well.

Could you please revert the lang datagen?