Biome-independent structure tables

[BoySanic]

Fixes #1805
Implements biome-independent structure tables.

The way these work:

Structure tables are loaded into the game along with all other assets.
When loading biomes, each biome checks its tags (new feature, currently unused) against the tags in each structure table that was loaded previously. If all tags on the table have matches in the biome's tags, add the structures from that table into the biome's internal structure table in memory at world load time.

Additionally, if a structure table has an empty .tags (len == 0), it should spawn those structures in all biomes. So those structures are added to all biomes' internal structure table.

Implementation details:

Moved SimpleStructureModel into src/server/terrain/structures.zig from src/server/terrain/biomes.zig.

Example structure table .zig.zon in assets/cubyz/structure_tables in this branch.

[BoySanic]

On the topic of this PR, I was thinking about how addons might target biomes and with the current approach they'd use biome tags.

I think it may make sense to allow the structure table to use the biome's id as a tag, too. Just check if the structure table's biomeTags contains the biome's Id (it would just be an or on the current check that is used) and it'd make that easier. Then we don't have to come up with tags to target specific biomes, we just use their id as a tag logically.

In the future I envision we start categorizing biomes. like cubyz:cold, cubyz:humid, cubyz:dry, cubyz:hot, and so on for the various "tags" that could apply to a biome. Then, similar to the #1805 example, maybe an addon that adds igloos would create a structure table containing that igloo and it would set its biomeTags to cubyz:cold or something, so the igloos are added to biomes that are tagged cubyz:cold.

[BoySanic]

I didn't mean to close that

[BoySanic]

Memory leak fixed, and I added migrations stuff to it for whenever someone needs to migrate structure_tables in the future. This should be good to go for review.

[BoySanic]

Whenever this is merged, #1283 can proceed as meteorites can be made into a structure table that spawns in any biome or biomes with specific tags. (Biomes currently have no tags, but coming up with those tags could be an issue on its own to discuss)

[IntegratedQuantum]

It'd also be good to have a configurable radius so structures don't spawn too close to each other.

There is a limit of a few blocks. Anything beyond that is not possible with the current, precomputed, blue noise map.

[BoySanic]

Hmm, maybe if a structure table had a .chance which itself multiplies each structure's chance in the table?

Yes, that would also be useful, but my proposal is different: limiting the total chance. This would make it easier to add structure variants without having to adjust the chance every time you add a new one. Like if I add a second meteor variant, I don't want meteors to be twice as common in the world.

Hmm, I see.

Should individual structure chances be normalized to fractions of the total chance on the full table?

(Like how we do structures in a biome right now, but instead of checking > 1, check > totalChance, and normalize so when summed they equal totalChance)

[IntegratedQuantum]

yes, though unlike biomes I'd say if present, it should always normalize to that value, even if it's below it.

[BoySanic]

I'm not entirely sure I got it right, but I implemented it

[IntegratedQuantum]

Also there are still traces of #2129 (comment)

Furthermore I want the structure table for that unique and never seen before structure from ikabod.

[BoySanic]

I'll remove the "torches_everywhere" and "meme" structure tables now that we have a real one added.

[IntegratedQuantum]

please fix the errors

[BoySanic]

Should be good to go