Handle projections validity area in Decimator and StreamingRenderer classes

Geometries that go beyond the validity area of a map projection should be handled instead of being dropped as done now.

The decimator and renderer classes should be modified to at least "cut" the geometries inside the validity area.
This may be a direct cut, or may be done in a more clever way by:

• splitting geometries spanning beyond the date line and the poles
• offsetting the parts that go beyond so that the end on the other side of the [-180,180,-90,90] envelope
• cutting the resulting geometries to stay inside the valid area.

Validity area is available for every projection that comes from an EPSG database, Martin Desruisseax says:

___quote start ________________________________________________________________________

If all the following conditions are meet:

• epsg-hsql, epsg-access or epsg-postgresql is available in the classpath;

• The source and target CRS contain their EPSG code in their metadata (it
  should always be the case if the CRS were created from an EPSG factory,
  even if this factory was epsg-wkt);

• The "sourceCRS to targetCRS" transform is one of those that are explicitly
  defined in the EPSG database (in the "Coordinate_Operation" table);

Then the "area of validity" should be defined as part of the CoordinateOperation metadata. This area of validity can be defined in various way, including string, geographic bounding box, envelope or arbitrary polygon (all this flexibility is provided by the ISO 19115 "Extent" object). It sound like that I didn't wrote a convenience method for extracting an envelope from a CoordinateOperation - we should probably open a JIRA task as a remainder that we should add such convenience method.

In the main time, there is a convenience method for extracting an envelope or a geographic bounding box from a CRS. So the easier way to check the "area of validity" of a transform is probably to invoke:

Envelope areaOfValidity = CRS.getEnvelope(operation.getTargetCRS());

Javadoc:

http://javadoc.geotools.fr/snapshot/org/geotools/referencing/CRS.html#getEnvelope(org.opengis.referencing.crs.CoordinateReferenceSystem)

Reminder: just in case you wonder what is the difference between an Envelope (from ISO 19107) and a GeographicBoundingBox (from ISO 19115): the Envelope can be in arbitrary CRS. The GeographicBoundingBox is garantee to be (longitude,latitude) in something close to WGS84.

All the above work only for CRS or CoordinateOperation explicitly defined in the EPSG database. If we want a general mechanism for computing the area of validity of an unknown coordinate operation, this require some though. There is no such general mechanism right now in Geotools.

__quote end_______________________________________________________________________