Adds fetchRange option to ERXFetchSpecification and fetchRange support to _MySQL.Plugin.MySQLExpression.

ERXFetchSpecificationBatchIterator in its current incarnation works fine for batching where a reference to the
batch iterator is maintained. However in direct actions, as used inside current ERXRestFetchSpecification.results(...)
method, a new ERXFetchSpecificationBatchIterator is created on each request resulting in the entire population
of primary keys being fetched and then the batch of EOEnterpriseObjects for the primary key range is fetched.

Having a fetchRange option in ERXFetchSpecification, with support in SQL PlugIns, enables the same range of objects
to be returned in one fetch in a stateless request. This is useful for stateless requests that request a range of
a huge population of objects. This feature may also not have the ERXFetchSpecificationBatchIterator
limitation of not supporting multi-column primary keys. Another advantage is that it has no limit to the total count of
the population of objects form which the range if fetched whereas ERXFetchSpecificationBatchIterator does have a practical
limit associated with ther total number of primary keys that can or should be fetched.

A disadvantage of direct SQL batch fetch is that for some complex qualifiers that return duplicate rows, the DISTINCT property
must be set to true to get accurate results. Having DISTINCT and ORDER BY in the same SQL statement apparently causes
problems in some database platforms such as Oracle that is taken into account by ERXFetchSpecificationBatchIterator
(see ERXSQLHelper.newSQLHelper(entity).shouldPerformDistinctInMemory(pkFetchSpec)) reference in primaryKeys() method
of ERXFetchSpecificationBatchIterator.
Just in case...
A few Enanchments to CCGoogleMap and CCGoogleMapMarker

Signed-off-by: Amedeo Mantica <amedeo.mantica@insigno.it>
Merge branch 'integration' of git://github.com/projectwonder/wonder into integration
Prevent java.lang.NoSuchMethodError: er.extensions.eof.ERXKeyFilter.include(Ljava/lang/String;)

This error only showed up in deployment on Sun version 1.6.0_27-b07 on Centos Linux but
on Mac build 1.6.0_31-b04-415-11M3646, java correctly called the varargs method with a single element array.
Strange but true.

Interestingly we have a single arg and a varargs variants of the same methods that take ERXKey parameters,
but did not have the single argument include(String keyName) variant. So we workaround this problem by
adding the single argument version for String which matches the method of the same name with ERXKey argument.

The exact versions of java are shown here:

Good version that did not throw NoSuchMethodError
	java version "1.6.0_31"
	Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3646)
	Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode)

Bad version that did throw NoSuchMethodError
	'java version "1.6.0_27"
	Java(TM) SE Runtime Environment (build 1.6.0_27-b07)
	Java HotSpot(TM) 64-Bit Server VM (build 20.2-b06, mixed mode)
Revert "Prevent java.lang.NoSuchMethodError: er.extensions.eof.ERXKeyFilter.include(Ljava/lang/String;)"

This reverts commit 8e039542a5f2e1d21604a0b3578a7c0f51a45cb9.

I guess I need to think twice about cherry-picking from my branch to integration.
Prevent null pointer exception
this class is not necessary anymore as of WO5.4.3
some Javadoc and minor fixes
Merge pull request #213 from kierankelleher/feature/125/FetchSpecificationRange

Adds fetchRange option to ERXFetchSpecification and fetchRange support to _MySQL.Plugin.MySQLExpression. 

ERXFetchSpecificationBatchIterator in its current incarnation works fine for
batching where a reference to the batch iterator is maintained. However in
direct actions, as used inside current ERXRestFetchSpecification.results(...)
method, a new ERXFetchSpecificationBatchIterator is created on each request
resulting in the entire population of primary keys being fetched and then the
batch of EOEnterpriseObjects for the primary key range is fetched. Having a
fetchRange option in ERXFetchSpecification, with support in SQL PlugIns, enables
the same range of objects to be returned in one fetch in a stateless request.
This is useful for stateless requests that request a range of a huge population
of objects, for example in a REST API. 

This feature may also not display the ERXFetchSpecificationBatchIterator
limitation of not supporting multi-column primary keys. Another advantage is
that it has no limit to the total count of the population of objects from which
the range is fetched whereas ERXFetchSpecificationBatchIterator does have a
practical limit associated with ther total number of primary keys that can or
should be fetched. 

Keep in mind that ERXFetchSpecificationBatchIterator, if suitable, is probably
still a better choice for stateful requests.

If a SQL query returns duplicate rows then the distinct option may need to be
set on the fetchspec to accurately return the expected results. If the fetch is
against an abstract entity the results may be unpredictable.
Merge branch 'integration' of git://github.com/projectwonder/wonder into integration