Previously the layer names used for geoprocessing were hard-coded.
As of #3399 we now have a number of NLCD layers, which may be used
for modeling purposes. To replace the NLCD layer in all operations
we switch to this tokenized scheme.

Now the operation definitions only carry the tokens, with a base
configuration defined with the previously used values. Both `run`
and `multi`, the two geoprocessing functions, now take an optional
`layer_overrides` dictionary, which is a mapping from token to
layer name. At run time, these overrides are combined with the
base configuration, which is in turn used to replace all tokens
with real layer names in the operation.

Since the cached value now depends on the layer overrides provided,
we now add them to the cache key. Any existing caches will have to
be deleted if ever we make changes to the default layers in base
settings.

Previously we had a separate JSON block for every NLCD year
for land analysis, which differed by only one line. Now, using
the new token feature, we reduce those to only one block, and
replace the tokens according to the requested NLCD year.

The schema validator is also updated to now use direct values,
since the nlcd_XYZ_ara configs are no longer available.

A hitherto unnoticed bug was revealed when the Analyze Land
endpoint switched to using tokenized instances of the same
JSON config: the token replacements would change the default
config itself, since dict.copy() is a shallow copy. This is
fixed by using copy.deepcopy() instead.

It is unlikely that this would have occurred in the past, as

  1. We used a separate JSON block for every geoprocessing
     run, rather than the same blocks as we are now with
     tokenization
  2. The contents of the JSON block were not changed other
     than adding the input polygon, which would be overwritten
     on every call