Implement ST_GetFaceGeometry by following rings, not face labels

[strk]

At the moment ST_GetFaceGeometry builds an area from the edges having the target face known to be on one of their sides. This requires re-determining edge connection when such information is already available (and used by GetRingEdges).

This ticket is to enhance the function to use edge linking instead, as it should be faster (no need to use the GEOS polygonizer) and more robust (would still work in case face labels are invalid).

Eventually, we could have a switch to decide whether to use face labels or edge linking.

Of course face label would still be needed to find at least one face edge for each face ring...

[strk]

Important info: this would NOT be easy to make faster than GEOS with only using SQL, as the already complex recusrive CTE used to find a ring of edges would need to be iterated to find *all* rings, and for faces with a lot of holes this would be very very expensive, unless it can be done with a single SQL statement

[strk]

For the record: we do have some C code to build polygons under the lwt_Polygonize function, we could do a single database access to fetch all edges advertising the given face on any of their sides and do the graph walking in memory. Note that the direct edge linking is not always enough as it would build Maximal Edge Rings while we'd need a Minimal Edge Rings to avoid self-intersecting shells invalidities (and dangling pointers).

[strk]

Reimplementing ST_GetFaceGeometry would help with performance issues like #4966

[strk]

One component of a reimplementation of GetFaceGeometry would be building the shell part, which is the focus of this merge request: ​https://gitlab.com/postgis/postgis/-/merge_requests/30