Review date and time handling for Java 8

Finished this up 2019-03-21.

After more discussion, we realized that it's a bad idea to allow any chance of nanosecond precisions from leaking into XML, so we reverted to using helper methods that enforce JAXP's parsing and serialization of both Instant and Duration by way of longs.

A side effect of this was the removal of a lot of extra DateTimeFormatter properties in the OpenSAML configuration and various XMLObject interfaces in favor of using the helpers consistently.

I believe apart from Ian doing some renaming of DOMTypeHelper methods, we're close to done on this.

IdP contained old javadocs to clean up, and one final use of Duration annotation that was converted over to Duration type. The use of a factory bean to handle scaling valus down to seconds/etc. should still work fine, just based on the Duration type as the input type to convert into first.

There may be remnants using longs somewhere but they aren't marked with a milliseconds comment in the docs, so will be difficult to find.

There are no longer any uses of Duration annotations in the code base, so we can now remove the annotation and the converter, which will require a lot of Spring test cleanup.

Remediated more APIs across the lower layers up to OpenSAML, based on searches for "milliseconds" in the Javadocs to locate longs used as instants and durations. Mostly internal changes, one or two things that I think are unused, but I left some deprecation warnings in on the use of Long objects in some configuration features.

IdP is TBD.

For what it's worth, this seems like the right approach to me too, for now. Both Duration and Instant}} do exactly what we want when you {{.toString() them, and I'm not upset by the idea that the value put in the XML might not be exactly what the JAXP library might generate as long as it's conformant.

When parsing, I'd be much warier about assuming that parsing operates identically for weird edge cases, not in terms of sensible-value-in-correct-value-out but for error and other exceptional cases.

So in the MDA use case, I'm probably going to end up going the same way: use .toString to generate values for the DOM, but continue to use the  DOMTypeHelper methods (mutated to generate appropriate types rather than just millis) for extracting values.