WL#7420: Geometry Collection Support

Boost Geometry(BG) doesn't have a geometry_collection type, but OGC defined such
a type, so we have to implement support for this type in all gis functionalty,
including spatial relationship checking, geometry set operations, and spatial
analysis functions, using BG's such functionality for the six basic types(point,
linestring, polygon, multipoint, multilinestring, multipolygon).

NOTE: In this text below, for the purpose of convenience and conciseness, 
we call the 3 types geometry, namely point, linestring and polygon, 
as "basic geometry(ies)";
and we call the 6 types of geometry, namely point, linestring, polygon, multipoint, multilinestring, and multipolygon as "member geometry(ies)".


F-1: Usage or data format shall not change, existing user code shall need no
change at all.
F-2: For all binary GIS functions, if both of the operands are geometry
collection that contains only one member geometry, the two member geometries are
put to geometric computation that work only for the member geometries;
otherwise do geometric computation algorithms dedicated for geometry collections.

F-3: According to OGC specifications for crosses, overlaps and touches, geometry
collections are not applicable to the 3 relation check functions, so we always
return false if at least one operand is a geometry collection(that has more than
1 member geometries).

F-4: For geometry set operations, if the final result is a geometry collection
that has only one component of the member geometries, the component is returned
as result;

F-5: For geometry set operations, if the final result is a multixxx geometry
that has only one basic geometry component, this basic geometry component is
returned.

F-6: A geometry collection operand is merged before sending it to the geometry
collection algorithms. By merge we mean 
1. union overlapping components of the same basic geometry type, 
e.g. union polygons and multipolygons, or union linestrings and multilinestrings;

2. union two components if one A is within the other one B --- the result is B.

so that finally the geometry collection consists of basic components
that don't overlap. This is important for all types of geometry computations to
get correct and most concise result.

F-7: If a geometry collection's components are directly computed by BG, we tag the
GC a 'nice' flag, those with 'nice' flag don't need to be merged because the
components
don't overlap.

F-8: Correct handling of one or both operand being an empty geometry collection,
and the non-empty one if any having arbitray contents or simply a member geometry.


NF-1: Use BG's rtree index to decrease geometry collection operations complexity
from O(N^2) to O(NlogN).

I-1: No new files.

I-2: No new syntaxes.

I-3: No new commands.

I-4: No new tools.

I-5: No impact on existing functionality. 

cross/overlaps/touches with one or both geometry collection argument isn't yet
implemented;

merge geometry components of same type before the set operation or relationship
check operation, this is crucial.