Allow differentiating every map for better modding

### Is your feature request related to a problem? Please describe.

Currently all maps have an om_terrain id, say "house_01" which corresponds to an type overmap_terrain's id. You're able to add a second map also with the id "house_01" so that when the "house_01" omt is spawned it randomly picks one of the maps using "om_terrain": "house_01" based on those maps respective "weight" (which defaults to 1000). This works fine but is both made redundant by the existence of nests which have more functionality, and means we can't add support to overwrite/extend etc different parts of a map or even overwrite the entire map through mods.

If a mod wants to change a vanilla map it currently it has 3 options:
- Add an altered version of the entire map with the same om_terrain id, making it a variant of the vanilla one, but giving it such a high weight that the vanilla variant never spawns in practice.
- Use an EOC defined variable as an external option weight for the vanilla version.
- Add the altered version under a different om_terrain id and override the special/multitile city building definition to use that version instead

All of these require duplicating the entire map entry, even if say you just want to add/remove a single item spawn or an NPC etc

By replacing all uses of shared om_terrain ids ~~, or adding some alternate way to reference map variants of the same id~~ this could be averted by using similar override/copy-from behaviours as most of the rest of our json uses, significantly reducing the size of mod alterations, removing the need to update changed modded versions of maps when making unrelated changes to vanilla (or the modded version falling behind) and increasing my sanity.
Same also goes for nested_mapgen_id s and update_mapgen_id s which also aren't unique ids rn (and are both type "mapgen" so it's probably easier to handle them at the same time).

### Solution you would like.

Enforce unique om_terrain/nested_mapgen_id/update_mapgen_id ids (om_terrain could also be renamed to overmap_terrain_id so it's more obvious it's referring to a type overmap_terrain's id)

~~The one issue with preventing shared om_terrain ids is that quite a few hardcoded maps make use of this I think, which might be non-trivial to resolve~~ This might prevent removing weight code for om_terrains for now but we can still remove reading it from json so it doesn't really matter and we're getting towards being rid of hardcoded mapgen finally anyway

### Describe alternatives you have considered.

_No response_

### Additional context

While I'm focusing on the benefits for mod maintenance here being able to know unique ids of everything allows things targeting maps to know what they're getting and is convenient for debugging.

No files, tests, or entry points are named. Start by tracing how om_terrain, nested_mapgen_id, and update_mapgen_id are read and resolved, including the overmap_terrain and mapgen JSON definitions. Done means these identifiers are unique and map variants can use copy-from or override behavior without duplicating entire map entries.

Written by the indexing model from the issue text.