Remove many hardcoded lists of layers and sources

While the Pelias project has intended to support custom data from day one, in practice much of the code was written largely under the assumption that the number of possible layers (distinct types of records) was limited and unchanging.

Over time we've found cases where these assumptions, while once convenient and simple, prevent people from fully using Pelias with custom data.

We need to go through the API code looking for cases where lists of layers (and sources, to a lesser extent) are hardcoded, and figure out ways to make them more extensible.

Some general guidelines:

Assume there are lots of non-administrative area layers

Thsese should be essentially equivalent to venues but with additional semantic meaning. Transit stops is a good example here.

Move towards the list of administrative areas being configurable as well

This is harder because admin areas also generally imply a hierarchy (countries contain regions, for example). In the long run, we want to support this not just in the API but placeholder and the PIP service as well.

Allow addresses and streets to be a special case, to an extent

Addresses and streets are unique because they are part of well-formed postal addresses, so capturing that relationship and meaning is useful. However, our code often assumes that venues, streets, and addresses are the only non-administrative area layers, which isn't good going forward.

Consolidate as much as possible into configuration driven lists

We recently created the TypeMapping object, which is a great place to add any lists that must remain. All those lists should be configurable.

Known hardcoded lists

• non-admin layers: https://github.com/pelias/api/blob/master/controller/predicates/is_coarse_reverse.js#L4
• non-admin layers: https://github.com/pelias/api/blob/master/controller/predicates/is_only_non_admin_layers.js#L9
• non-admin and admin layers: https://github.com/pelias/api/blob/master/controller/coarse_reverse.js
• Non admin layers in https://github.com/pelias/api/blob/master/sanitizer/_geonames_warnings.js#L3
• Big hardcoded list of admin layers: https://github.com/pelias/api/pull/780
• Admin layers: https://github.com/pelias/model/blob/master/Document.js#L9-L26
• list of admin placetypes https://github.com/pelias/api/blob/master/helper/placeTypes.js
• non-admin layers for reverse queries against Elasticsearch: https://github.com/pelias/api/blob/c69a9609040ac7fedb09000ae5f9ec5518ffe2be/query/reverse.js#L43

Start by auditing the listed API files, including controller/predicates/is_coarse_reverse.js, controller/predicates/is_only_non_admin_layers.js, controller/coarse_reverse.js, sanitizer/_geonames_warnings.js, helper/placeTypes.js, and query/reverse.js. Read the TypeMapping object and the referenced pelias/model Document.js admin-layer definitions to understand which lists remain necessary. Done means the identified hardcoded layer and source lists are consolidated into configurable structures that support custom layers across the affected API paths.