Handle WMS layers more gracefully

[steff-o]

Possibly related to #8, but for WMS.

Todays implementation handles WMS layers (and all other non-vector layers) by assuming there is a WFS endpoint at the same url as the image layer. This may very often be true when it comes to WMS:es hosted by the own organization as Geoserver for instance default have both WMS and WFS enabled. But for many other setups this assumption will fail.

Suggested ways around this:

1. Add a configuration if the WFS endpoint should be tried.
2. Implement something like featureInfoLayer configuration to make it possible to point out any arbitrary layer to get features from.
3. Implement something that actually fetches the features from WMS.

Solution 2 would probably require some additions to the core, either a touch up of the getFeatures utility function to support different SRS and possibly some other changes to make it more versatile or move the getFeature functionality to a VectorSource class. At least getFeature and the VectorSource should be consolidated in some way to avoid the loader function to be almost exactly the same as getFeatures, but that's an issue for the core. Maybe its possible to extend the featureInfoLayer handling in core to allow for more layer types and expose that functionality as an api function using an extent as input instead of just a point.

Solution 3 kind of defeats some of the reasons to use WMS, but could be possible using vendor specific parameters to getFeatureInfo. Geoserver has a search radius parameter which could be used to create a query that fetches the outer circle of the extent and Qgis server has a vendor specific parameter that can take an intersecting geometry. For other server types (AGS WMS etc) this approach will not work unless there is a vendor specific parameter as the WMS standard only specifies a X,Y pair to query.

[filleg]

This would be a great improvement. We have a similiar solution as number 2 in our current internal map setup (sMap). QGIS server as backend. Going forward solution 2 seems feasible and friendly in terms of configurability.

[steff-o]

Another issue with the approach of automatically call a WFS service is that filters on the WMS layer i ignored. We have a case where the CQL filter of the WMS layer is updated dynamically, which makes it even trickier to make multiselect respect it, as getFeature() does not handles filters and we can't create a pre-configured query layer using the same filter.

Sometimes I say to myself: "If it is so much trouble selecting in WMS, why not switch to WFS?". There are three answers to that:

1. Some public servers only publishes WMS. these may be hard to make it work for, as not all allows getFeatureinfo.
2. Large datasets gets pretty slow in WFS.
3. Because it is possible.