Expose SFCGAL's 3DIntersects as CG_3DIntersects

[robe]

Prior to PostGIS 3.0, we had a backend guc that allowed to specify which function to use when overlapping functions between postgis and postgis_sfcgal.

This switch was removed cause most overlaps were redundant or the postgis version was better and functions such as ST_3DIntersects were augmented to handle TINS and POLYHEDRALSURFACE, which were the reasons why anyone would want to use the SFCGAL implementation.

However there are some corner cases where the SFCGAL version is just better. There is also the issue of solids. postgis ST_3DIntersects does not have a concept of solids where as sfcgal does understand the difference between a solid and a surface.

That said we need SFCGAL 3DIntersects back and eventually perhaps rename others with prefix CG, so we don't have to have arguments when SFCGAL has some function that GEOS now has like the whole e.g ALphaShape stuff we had recently.

Thoughts?

My main question is CG good prefix. I avoided SF cause that sounds like spatial features. And SFCGAL_ seems too long.

[robe]

Oh wait I thought of another option and then we wouldn't need to rename existing functions

How about ST_3DIntersects with a backend arg e.g.

boolean ST_3DIntersects( geometry geomA , geometry geomB, text backend='geos' );

[robe]

scratch the idea of overloading ST_3DIntersects. I realize now that won't work. It would have worked pre 3.0 because at the time, all the SFCGAL functions were embedded in the postgis-2.5 live. But since we broke that out to be postgis_sfcgal, the overload I don't think is a viable option.

[lbartoletti]

Some SFCGAL functions have already SF_ prefix. But, it's ok to me to use CG_ prefix for SFCGAL.

[robe]

This is a dupe of #5405