Conflicts:
	src/main/java/org/orekit/frames/FramesFactory.java
	src/main/java/org/orekit/frames/MODProvider.java
	src/main/java/org/orekit/overview.html
	src/site/apt/architecture/frames.apt
	src/site/apt/index.apt
	src/test/java/org/orekit/frames/FramesFactoryTest.java

Bulletin A provides rapid service and prediction, whereas bulletin B
provides final values. Bulletin A are suitable for real-time operation
and bulleting B more oriented towards a posteriori accurate analysis.

Tabs, trailing spaces, non final variables and javadoc.

Thomas Neidhart authored Aug 18, 2014 and Luc Maisonobe committed Aug 18, 2014

 - GeoMagneticField.getDecimalYear() returned a slightly wrong result:
   e.g. for 1/1/2005 returned 2005.0020 instead of 2005.0,
 - GeoMagneticFieldFactory.getModel() returned
   wrong interpolation near models validity endpoints,
 - GeoMagneticField.transformModel(double) method did not check year
   validity.

Added more unit tests and adapted existing tests for IGRF/WMM with
sample values / results as they have changed slightly.

Fixes issue #178.

When filtering first from satellite ID and then extracting closest date,
the returned satellite was sometime wrong.

Thanks to Patrice Mathieu for the bug discovery and analysis.

Thanks to Hank Grabowski for the patch!

Fixes issue #176.  

Implemented from Montebruck and Gill.

Thanks to Ioanna Stypsanelli!

This was the last par still in apt format. Now everything uses markdown.

Due to how parameters were set in
NumericalPropagatorBuilder.buildPropagator(...) all parameters are set to the
last value. This error was not detected by the test cases because the test case
used Cd with an orbit that is not sensitive to drag.

Also fixed for TLEPropagatorBuilder, though it will have no effect since the
builder only supports one parameter.

In PartialDerivativesEquations the velocity is set incorrectly. This causes
force models that depend on velocity, such as drag, to report incorrect
derivatives. Also added a test case to check this bug.

Extracting the LOD correction from EOP is done at TIRF level since a
few months ...

Extracting the pole correction from EOP is done at ITRF level since a
few months ...

This change prevents an error with Java 7 compilers as there is a
conflict between two different static methods in base class and subclass
that have same type erause.

It also prepares another future change where a third derivative can be
optionnaly used in interpolation: linear and angular acceleration.