Also remove Propagator.DEFAULT_LAW. Use IntertialProvider.of(Frame)
instead. See discussion on !189. Part of #586.

Previously when an analytic propagator handled a continue event the
first part of the step would be passed to the OrekitStepHandler twice.
Now it is only passed once. Seems to have been present when
AbstractAnalyticalPropagator was created, about a decade ago, and not
detected in all the changes since then, so I guess no one uses that
combination much.

Previously when there was a step handler analytic propagators were
forced to take small steps though EventDetector and OrekitStepHandler
can both use large steps. Removed this unnecessary restriction to
improve performance.

Fix #830

Previously a null reset state behaved as CONTINUE with analytic
propagators but not with integrated propagators. This was an
undocumented "feature". Removed it to be consistent.

Previously ClasspathCrawler matched the whole path against supported
names which caused problems with ^ as other loaders only matched the
file name. Added a test case.

Implemented for all analytic and the GlONASS propagator. The DSST and
Numerical propagator do not have a frame available in their constructor,
so the new behavior could not be implemented. Aligning the attitude
frame with the propagation frame speeds up propagation when the user
does not care about attitude and it many cases it removes a dependence
on the default data context.

Fix #586

It now has better performance when the attitude is aligned with the
propagation reference frame by avoiding multiplying by zero. With
analytic propagators using this attitude provider instead of the default
has been observed to result in a speed up of 2 in some cases, e.g. with
the TLEPropagator.

For #586

Improve exception messages with AbsoluteDates by including the duration
between the dates. Many messages updated, some new messages added.

Part of #825

Now the toString methods of AbsoluteDate include an indication of the
UTC offset where the UTC time scale is clearly specified. The
toString(TimeScale) method does not append a UTC offset indicator since
that method can generate strings for any time scale and it is not clear
from within the method if the time scale is intended to be UTC.

Updated some TimeSpanDragForceTest to use toString(TimeScale) because
that is what is used in the production code. Updated other tests to
include "Z".

Fix #637

Fall back to TAI and then fall back to seconds past epoch. Since this
method is used in so many exception messages this will prevent the
original exception from being discarded and give the user some
indication of the time.

Part of #825

Previously the DateTimeComponents, TimeComponents, and AbsoluteDate
toString() methods did not include the UTC offset. UTC offset is part of
TimeComponents and the method signature of some toString() methods so
it's ommission did not accurately represent the data. In ISO 8601 if the
UTC offset is missing then times are interpreted as local, which is not
intended. Added methods for printing without the UTC offset as well. The
AbsoluteDate.toString(TimeScale) and AbsoluteDate.toString() methods
still do not print the UTC offset because many time scales have
non-integer minute offsets to UTC which is not supported in ISO 8601.

Previously DateTimeComponents.toString() could not print times during
leap seconds. Now it can.

Previously the DateTimeComponents and TimeComponents toString() methods
could round up to invalid times when within 0.5 ms of the next minute.
Now they do not round up because they print additional digits when
necessary.

These are backwards incompatible changes.

Fixes #637, #590, #591

Fixes #828

Fixes #827

Fixes #820

Fixes #799

Fixes #821

Fixes #819

Fixes #814

They have been replaced by a versatile step handler multiplexer
fulfilling all these needs simultaneously during a single
propagation run.

Fixes #809

Fixes #812

Fixes #813

Fixes #811

Fixes #810

Fixes #808

Fixes #807

Fixed #806

Fixes #796

This occurs in very rare cases due to numerical noise.

Fixes #792

Fixes #783

Fixes #782