Differenent cache capabilities at different OCPL sites

[following5]

This is closely related to #578 and blocks #570.

OCPL sites have different sets of cache sizes, but services/caches/capabilities currently ignores that. It returns the same set of basic sizes for all OCPL sites. (This is uncritical as long as full cache editing is not deployed. Also, so far no client did query the capabilities.)

In the future, this may also apply to cache types. Theoretically also to cache countries, regions and description languages.

OCPL cache sizes and types currently are redunantly definied in code and in (legacy) DB tables. For sizes, it currently is proposed to consolidate that to the code (=> Config/site.*.php). How can OKAPI access those definitions?

Easiest solution for OKAPI would be if the OCPL DB tables are retained and automatically maintained via new database update system (update them with each code deployment). Then we can handle it the same for OCPL and OCDE. Only the id fields would accessed by OKAPI.

[following5]

Removed services/caches/capabilities by 72e03f7, and restored old search docs.

[andrixnet]

I think maintaining the same information in multiple places is a bad idea.
Since opencaching-pl has begun moving data definitions to code, this should be a general rule, not a another mixture.

IMO the code [opencaching-pl] should define all possible cache types, all possible sizes, all possible attributes, etc.
Settings for individual nodes (websites) should enable or disable their desired features.
The code should have a method to report enabled features for this instance, according to configuration, method accessible to OKAPI to obtain the necessary information.

However duplicating definitions from the code into a database table is needless complication of code, database, website and database performance and ultimately user experience.