Thanks to Lucian Barbulescu for providing the translation.

Thanks to Lucian Barbulescu for spotting the issue.

The Eckstein-Hechler propagator now generated Cartesian orbits, with
velocity computed to be fully consistent with model evolution. A side
effect is that if users rebuild circular parameters from the generated
orbits, they will generally not math exactly the input circular
parameters (but position will match exactly).

Fixes issue #180.

It is *normal* that initial circular parameters are different for
Eckstein-Hechler propagator.

The GenericTimeStampedCacheTest shutdown the test thread pool after waiting for
3 seconds for all of the threads to complete. On some systems the three seconds
is not enough and causes a test failure as the test does not see the expected
number of method calls.

I increased the timeout to 10 minutes, and added a message in case this happens
again.

The two pairs constructor is not as lenient about its input parameters
than the corresponding constructor in class Rotation. The javadoc now
explains it. 

NaN may appear if the spacecraft enters inside either the occulting or
occulted body sphere. Of course, this should not appear with resonable
settings, but it occurred at least once in tests with an EventShifter
configured to used a huge unrealistic offset, for which the underlying
shiftedBy method was clearly not sufficient to meet accuracy needs.

The base attitude was specified to have velocity roughly in the +X
direction, but recent changes reverted it in the -X direction.

Since PVCoordinates now include acceleration, it should be computed xith
non-Keplerian effects when non-Keplerian propagators are used.

Conflicts:
	src/site/xdoc/changes.xml

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.