Standardize sub-national entities and their relationship with the "region" option

[anth-volk]

At the moment, we use "region" to refer to many different things:

1. "primary" entities within the international realm ("the US", "Canada")
2. "secondary" entities ("England", "Texas")
3. We will begin using it to refer to "tertiary" entities within the UK (the riding of Windsor, the Hammersmith & City borough council)
4. In one deprecated case that we provide backwards compatibility for, a dataset applied to a primary entity ("enhanced_us")

This is limiting and can be confusing.

In terms of limitations, take the example of the UK. From a front-end perspective, by disambiguating, we could create selectors that only show some of these types of regions, but not all. From a back-end perspective, there's unexplored opportunities, e.g., we could create a response type whereby we provide all individual tertiary-level impacts within a secondary entity, e.g., all constituency-level impacts in Scotland.

In terms of the confusion, treating these all as regions means that we either have to 1. manually manipulate the entire region list and remove certain types of entities for certain types of simulations we don't want to run over them (quite a pain) or 2. ensure all regions can handle all simulation types (which may not be the case).

[MaxGhenis]

Could you say more how we'd standardize this? We will likely want to add more geographic identifiers in the future. Ideally we could map as many as possible from something fine-grained (e.g. ZIP/postal code) and impute those in microdata for consistency.