Fixed exception of WFS if requested feature (by resourceid) does not match the requested feature type (by typenames)

[dstenger]

Previously, when a requested feature (by resourceid) did not match the requested feature type (by typenames) a FeatureCollection was returned.

The WFS 2.0 specification (09-025r1) states that an InvalidParameterValue exception is expected (Chapter 7.9.2.4.1 typeNames parameter, page 34):

For KVP-encoded ad hoc query expressions the typeNames parameter shall be encoded 
using the TYPENAMES keyword (see Table 8). The TYPENAMES parameter is mandatory 
in all cases except when the RESOURCEID parameter is specified. In this case the 
TYPENAMES parameter may be omitted because each feature instance can be 
identified by its resource identifier alone (see 7.2). If both the TYPENAMES and
RESOURCEID parameters are specified then all the feature instances identified by 
the RESOURCEID parameter shall be of the type specified by the TYPENAMES 
parameter; otherwise the server shall raise an InvalidParameterValue exception 
(see OGC 06-121r3:2009, Table 25) where the "locator" attribute 
(see OGC 06-121r3:2009, 8.4) value shall be set to "RESOURCEID".

This fix corrects the behaviour of the WFS and an InvalidParameterValue exception is returned instead of a FeatureCollection for the pictured case.

Following test of the OGC CITE WFS 2.0 test suite [1] is now passed due to this fix:

• "inconsistent Feature Identifier And Type"

[1] http://cite.opengeospatial.org/teamengine/

[tfr42]

Please enhance this PR to support this for the blob modus as well. See line 969
https://github.com/deegree/deegree3/pull/718/files#diff-0c919f1b05b23e814f31e8211037305bR969

 if ( blobMapping != null ) {
              return queryByIdFilterBlob( filter, sortCrit );
          }