Fixed empty GFI response on a FeatureType with multiple geometry columns

[lgoltz]

Currently a GetFetureInfo requests based on FeatureLayer uses the first geometry column, to match the requested click point. This geometry may differ from the geometry used to render the GetMap request or may be empty,

This PR fixes this by using the same geometry property for GetFeatureInfo requests from the style as the GetMap request.

Fixes #1640.

[julianzz98]

The fix was successfully tested on a local environment!

[tfr42]

@julianzz98 How does the GFI request/response changes when the tunable deegree.sqldialect.consider-all-geometry-columns is enabled or not?

[stephanr]

We discussed this PR in yesterday's TMC meeting, and from the currently supplied information in this PR, the following questions arose:

• It looks like this PR will change the behavior of deegree, which currently would be included in an incremental update that may or may not surprise users.
• This PR shares similarities with Enhanced bbox requests without geometry property to consider all geometry properties (3.6) #1732 where, after discussions about the behavior change, it was changed to be opt-in via tunable. And visually it is unclear if and how both PR are related to each other.
• Does the change in by including more geometry properties have a security implication by widening the scope for the query to the datastore?

To go into detail about the security implications here, as discussed in the TMC meeting, it is unclear if the additional filter will widen or narrow the feature requested from the feature store (are more features returned, or are only the same features returned and correctly selected for rendering)?.

With the current supplied information, this question could not be answered.

So in my understanding, a WMS GetFeatureInfo should request the same features as a WMS GetMap would do and then filter out the features requested by the GetFeatureInfo click position.

So one way to better understand the implications of this PR would be to document the SQL before and after applying this PR to see if there are security implications. (Maybe also with and without the tunable of #1732, if this changes the behavior.)