This allows the same model to be forward and reverse geocoded and still
provide a geocodable address though a non-attribute method. Also raise
an exception if sufficient configuration is not provided.

Move relevant methods into it.

Be more descriptive.

Move all network/lookup-related methods into it.

Move some methods into it (organize!).

This fixes an incompatibility with the will_paginate gem.

This fixes SQLite near methods and speeds up MySQL and Postgres.

Add a GROUP BY clause which yields correct SQL. (Incorrect query is
accepted by MySQL and SQLite but not PostgreSQL.)

Stop allowing full :conditions option to near_scope_options (was
deprecated, now it's gone). Update installation documentation.

Should be slightly faster and we avoid an ugly REXML require statement.

"bad" = non-200 HTTP code

We were checking for a blank query in fetch_coordinates, now we do it in
_fetch_xml.

Was using version 2. Version 3 no longer requires an API key so this is a big
improvement to the getting started experience.

The 'nearbys' method previously returned an array. It now returns a scope,
which is much better. It was also passing an options argument to
default_near_scope_options which was being ignored. It is no longer ignored,
but passing options this way is now deprecated due to the scope chaining
syntax provided by Rails 3. Support for Rails 2 will be discontinued soon,
or at least moved to a different branch.

The method was removed from Rails 3 RC 1, though it appears it will be
included in the final release. See:

Removed:
http://github.com/rails/rails/commit/b0b9bf320409b66c6c6b680371aca590297cd4cc

Reinstated:
http://github.com/rails/rails/commit/88b5f938cf7d3eb26ad204451a4dbb9c2cf4f571

This option is not recommended but it must be available for consistency.
The API should support the same options regardless of the algorithm used
for finding nearby objects.

Also move shared :conditions to default_near_scope_options.

PostgreSQL doesn't support the "X,Y" format for the LIMIT clause, and this
is proper use of ActiveRecord anyway.

In response to bug reported by Github user kenzie.

Avoid using column aliases in the HAVING clause (not allowed by
PostgreSQL).

This less accurate SQLite-compatible implementation is activated
automatically if an SQLite database is being used.