Support for Layer Groups, Layer Meta-Information and External Layers

[cklein05]

_This comment is not yet complete. It covers a complex topic and I try to be very clear and correct, which takes some time. I will continue writing on it as time permits. This remark will be removed upon completion._

Introduction

There are some ideas of extending the features of OGCServer. Notably, these features are configurable named layer groups published through the capabilities documents, providing much more map and layer specific meta-information in the capabilities documents as well as support for providing external layers. The latter may come from other WMS servers, so this will make OGCServer a cascading WMS server. This also includes introducing a new, maybe additional, configuration file with a hierarchical structure, most likely in JSON format.

Let me first please define some basic specifications for supporting layer groups and other layer meta-information and for having a new, maybe JSON style, configuration file.

Configuration Files

After thinking about it, I do not recommend to completely replace the current configuration file ogcserver.conf with the new hierarchical wms.json or layers.json file. There are many plain (non hierarchical) and mostly internal or technical configuration options, that are not suitable for being stored in a JSON file. At current, this only applies to the module and to the maxage option. However, some of my next PRs will introduce some more of these basic configuration options.

Most of these basic options are OGCServer and implementation specific, so these need additional documentation (in contrast to WMS layer meta-information for example, which are explained by WMS specs). Since JSON basically has no support for inline comments, storing these in a file with a plain old configuration file format (like of the current ogcserver.conf file) is preferred.

Furthermore, for my understanding, all these new features, like layer groups, layer meta-information and external layers, shall be optional. That is, the server must also work without these configurations, by using proper default values. So, moving these into one ore more separate configuration file(s), which must not be present, is probably a good idea.