fix the geometry of a column a sub-decoder derives from an expression

[cportele]

This PR fixes an unrelated issue for an edge case (geometry properties with an SQL expression) that was discovered while working on #618. The changes build on top of #618.

SqlQueryColumnOperations told the dialect whether the expression yields a geometry by passing "the column has the WKT operation". A geometry column carries exactly one of the WKT and WKB operations, chosen by queryGeneration.geometryEncoding, so with the default encoding of WKB the dialect was told the expression is not a geometry and returned it unwrapped. Every other consumer of these operations looks at both.

Three defects followed from that, in both the PostGIS and the GeoPackage dialect:

• a geometry was returned as the raw value of the database instead of the requested encoding
• the spatial extent query excludes the WKT and WKB operations because it wraps the raw geometry itself, but the exclusion was not honoured, so the geometry was wrapped twice
• forcePolygonCCW and linearizeCurves were not applied, so the same geometry came back differently depending on whether it was reached through an expression

The dialect is now given the operation instead of a flag, along with the two geometry options. It cannot hold the encoding itself: it is shared by all providers of its DBMS, while the encoding is set per provider, which is why the field that used to be consulted for it was never assigned.

Both dialects implemented the method identically, so it moves to the interface, where it calls the WKT and WKB rendering of the dialect.

For correctly configured geometry expressions, the Oracle and DuckDB dialects are handled properly.