Implemented response paging for WFS 2.0.0

[lgoltz]

This pull requests adds the response paging functionality to WFS 2.0.0. If a GetFeature request is sent (with a count value), the response contains @next and @previous attributes which contain URIs to the next or previous features (number = count value). By using that URIs, the user can page forward and backwards through the features. In the capabilities the constraint "ImplementsResultPaging" states that the response paging functionality is enabled. Currently, the implementation is not transaction safe. This is stated by the constraint "PagingIsTransactionSafe" which is always set to false.

Currently @next and @previous URLs bases on the original GetFeature request in KVP encoding.
Response Paging works only when streaming is disabled.
By default, WFS 2.0.0 does not support response paging and it can be enabled by configuration.

[copierrj]

There is a lot of stuff in this PR that is not directly related to response paging. Could you explain why all these things are needed to implement paging?

[stephanr]

Can you please explain how the change handles the offset and pageing in more detail please ?
Is the compute work done by the database using extra limit / offset syntax or by skipping the first n entries ?

[dstenger]

The next and previous URLs base on GetFeature request which can currently already be handled by deegree.
Example:

• http://localhost:8080/deegree/services/wfs?service=WFS&request=GetFeature&version=2.0.0&typenames=Test&startindex=0&count=10

The response paging mechanism uses the incoming URL and just adds/ manipulates the startIndex and count parameters. In addition, the mechanism determines if there is a next or previous URL and just adds the next/previous attribute to the response if there is a corresponding URL.
The new encoder classes are used to encode an incoming request to a map, which is needed to build the next and previous URLs.

[tfr42]

The Filter200XMLEncoder is required to process a incoming GetFeature request using paging functionality.

[copierrj]

Fixing #648 would make this functionality scale a lot better