inconsistent ownerhips rules from liblwgeom mediated GEOS constructive functions

[strk]

The functions lwgeom_clip_by_rect, lwgeom_difference, lwgeom_symdifference, lwgeom_intersection, lwgeom_unaryunion, lwgeom_linemerge (and maybe others) contain short-circuits that simply return a clone of one of the arguments, but the clone is not deep so that the caller doesn't know if the arguments can be freely released w/out destroying the return.

For consistency reasons it'd be good to always give the caller a fully owned object.

I think this problem goes back as long as 2.0, but not sure if it is worth fixing that much in the past.

[strk]

lwgeom_split is also affected

[strk]

r13942 fixes this problem in trunk (2.2.0). Alessandro: is spatialite use of liblwgeom from PostGIS 2.0 and 2.1 possibly affected by this issue ? You should be able to test by using any of the aforementioned functions with an EMPTY argument and checking memory for errors or leaks (there would be no error nor leak if you release the non-empty argument _after_ using the return object).

[strk]

Well, I decided to backport this to 2.1 branch, with r13944 (2.1.9) — won't do 2.0