Replaced WALK,BICYCLE mode with WALK,BICYCLE_RENT in bikeshareModule
Add CompactLineString implementation.
Add CompactLineString unit test.
Use CompactLineString in PlainStreetEdge.
Remove unnecessary setup(), called in constructor.
Add variable length int encoder/decoder utility.
Add variable length int encoding unit tests.
Use var length int coding in CompactLineString.
Update CompactLineString doc with latest changes.
Make Dlugosz int packer null-safe.
Remove CompactLineString instances, store byte[].

As suggested by Andrew.
This shaves off ~1.3% of graph size on street-data only graph.
Add config file Preferences implementation

This config file format was proposed on mailing list:
https://groups.google.com/d/msg/opentripplanner-dev/tk427ITino0/NARvCmyfKPoJ
Update CompactLineString with new version.
Implement a fast version of DirectionUtils.azimuth.

The default version is exact (take into account spherical geometry) but insanely expensive.
Replace with an equirectangular projection approxmimation (10 times faster and precise
enough for our purpose of computing nearest edges azimuth score (drive mode) and relative
directions from a 100m street to the next.

Benchmark for 1000000 computations:
- 5535 ms for the exact version
- 375 ms for the approximate version.
Add unit testing for DirectionUtils azimuth stuff.

Test performances, and non-regression (max error).
More tests for invalid config file input.
Implement a fast version of DirectionUtils.azimuth.

The default version is exact (take into account spherical geometry) but insanely expensive.
Replace with an equirectangular projection approxmimation (10 times faster and precise
enough for our purpose of computing nearest edges azimuth score (drive mode) and relative
directions from a 100m street to the next.

Benchmark for 1000000 computations:
- 5535 ms for the exact version
- 375 ms for the approximate version.

Update unit testing with correct azimuth on artic and new approximations (91 vs 90 degrees).

The azimuth in artic region is now correct
(going from 180,90 to 180,89 is indeed going SOUTH).
Add unit testing for DirectionUtils azimuth stuff.

Test performances, and non-regression (max error).
Add meters to lon degree depending on latitude.

This will help in calculating better fitting envelopes for speeding
up spatial index lookups. And solving some bugs/features on the way the
nearest streets/vertices are found too...
Add meters to degree conversion unit tests.