Move access_mapping out of configuration file?

[arporter]

In #3263 I am changing the access-type used to describe reduction accesses. (Currently we only have GH_SUM and will generalise this to GH_REDUCTION.) In doing this I've realised that I'll have to change the configuration file as it contains:

# Settings specific to the LFRic API
# ==================================
[lfric]
access_mapping = gh_read: read, gh_write: write, gh_readwrite: readwrite,
                 gh_inc: inc, gh_readinc: readinc, gh_reduction: reduction

Changing the configuration file in this way will mean that every user will have to update their local configuration file otherwise they'll get an error at run-time. This is not good.
I also don't understand why we have this mapping in the configuration file in the first place - it's really not a user-configurable thing.
I therefore propose to move this mapping into lfric/gocean_constants.py which is where it belongs as that's where the list of valid reduction types is defined. I also propose then having the code that handles the configuration file log a deprecation warning if it finds an access_mapping entry but otherwise continue without erroring.

What do @TeranIvy, @christophermaynard, @hiker, @sergisiso and @LonelyCat124 think?

[hiker]

I can't remember why it is here, and I am happy to see it go. I would just prefer to add the tests as deprecation tests (and not immediately fail if these symbols are still defined in the config files), so that users have time to update the config files (e.g. in LFRic).

[arporter]

not immediately fail if these symbols are still defined in the config files), so that users have time to update the config files (e.g. in LFRic).

Yes, that's what I was intending.