Overall strategy for normalisation of coordinate and variable names

### What problem does your feature request solve?

Currently variable and coordinate names are handled in an ad-hoc manner. UM variable names/STASH codes are converted to LFRic names, and coordinates require bespoke loading callbacks to fix them. This means our coverage is never complete, is not stable or reliable, and conversion is spread throughout the code.

### Describe the solution you'd like

We should define a single source of truth for what variables are equivalent, convert them in one place, and also handle coordinates in this strategy. As well as names, units should also be considered.

### Describe alternatives you've considered

The big consideration with this is what we normalise to. The two reasonable choices are the output of a particular model, most likely LFRic, or [CF standard names](https://cfconventions.org/Data/cf-standard-names/current/build/cf-standard-name-table.html).

My instinct is to push hard for CF standard names, as then we unlock interoperability with other community tools, and are not just working in an Met Office/LFRic silo.

While there may be variables that are not standardised, they are likely to either be so model specific that they are not useful to compare between model, or *should* be standardised, in which case we should work with the upstream CF conventions to get them standardised.

The issue names no files, tests, or entry points; begin by tracing the existing UM/STASH-to-LFRic conversions and coordinate loading callbacks. Compare normalising to LFRic output with using CF standard names, then define the single source of truth to cover variable names, coordinates, and units.

Written by the indexing model from the issue text.