7649 api key settings

DO NOT MERGE.

The current branch prioritizes the engine settings in the current implementation. I think it would be desirable to be able to override engine settings in the application, instead of the other way around, but don't have a particularly great way of doing that right now. 

I wanted to have some discussion about it before putting any serious work into it; but don't think this should be merged to ```develop``` until it is done.

Also closes #7672.
```rails_config``` loads various configuration files in a specific order (with later files overriding the contents of earlier ones. The order, as implemented here, is as follows:

```
# all are relative to Rails.root
# {env} is the environment if it is 'development' or 'test'

# note that the issue called out in the PR description is to move ./v1/config and ./contentqa/config above the ./config paths, giving priority to settings specified in the host application.

./config/settings.yml,
./config/settings/{env}.yml,
./config/environments/{env}.yml,
./config/settings.local.yml,
./config/settings/{env}.local.yml,
./config/environments/{env}.local.yml,
./v1/config/settings.yml,
./v1/config/settings/{env}.yml,
./v1/config/environments/{env}.yml,
./v1/config/settings.local.yml,
./v1/config/settings/{env}.local.yml,
./v1/config/environments/{env}.local.yml">,
./contentqa/config/settings.yml,
./contentqa/config/settings/{env}.yml,
./contentqa/config/environments/{env}.yml,
./contentqa/config/settings.local.yml,
./contentqa/config/settings/{env}.local.yml
```

One of the benefits of this approach is that there's no need to have ```dist``` files, or to place the burden on developers to manage configuration when they check out the repository.  Instead, you can distribute default values on an application-wide, or environment specific basis.  If you want to change the config locally you can use a relevant ```.local.``` file; in this case: ```./contentqa/config/settings/test.local.yml```