Rename units to locations

[timtroendle]

The name units that is used heavily in the workflow stems from "administrative units". We may want to consider renaming them to locations.

These are the reasons:

1. With eHighways being built in, not all locations are administrative.
2. The abbreviation units for "administrative units" isn't clear and many people may not even know what it means.
3. Calliope uses locations and we would be consistent.
4. We already use locations in some places, leading to inconsistent code like locations = rules.units.

[timtroendle]

This is up for discussions. @calliope-project/euro-calliope-devs happy to hear your opinions.

[irm-codebase]

@timtroendle I believe the preferred naming in Calliope 0.7 is nodes. So perhaps we should use that?

See: https://calliope.readthedocs.io/en/latest/math/base/

[jnnr]

I agree that a consistent naming will help. However, 'node' is a graph theory term and doesn't really fit in the context geospatial data processing of euro-calliope, in my view. I propose either regions or spatial_units, which were both terms we used consistently in our sprint week spatial resolution team.

[sjpfenninger]

As of Calliope 0.7 we do use nodes inside Calliope itself, not locations. But perhaps using locations in the euro-calliope processing chain all the way up to the end, where the Calliope model is built (where nodes will then be mandatory), helps clearly separate the data processing from the model building.

[jnnr]

Distinguishing the nodes of the calliope model from the regions in the data pipeline makes sense. Still, I'd favor regions or spatial_units. A location commonly refers to a point, but what is now called units are not points, but polygons with an extension.

[brynpickering]

regions has the problem of possibly being mixed up with the regional resolution of the model. spatial_units could work. There's also zones and geometries