Date/Time parsing: Use java time API instead of exception handling

[spinscale]

when several formatters are used, the existing way of parsing those is
to throw an exception catch it, and try the next one. This is is
considerably slower than the approach taken in joda time, so that
indexing throughput is reduced when a date format like x||y is used and y is the
date format being used.

This commit now uses the java API to parse the date by appending the
date time formatters to each other and does not rely on exception
handling.

This also removes the MergedDateFormatter class, is this kind of
work can now be done before the class is created.

The stats of the added benchmark before this patch

Benchmark                             Mode  Cnt     Score     Error  Units
DateFormatterBenchmark.parseJavaDate  avgt   30  5638,653 ± 135,143  ns/op
DateFormatterBenchmark.parseJodaDate  avgt   30  1094,825 ±   8,526  ns/op

with this patch

Benchmark                             Mode  Cnt     Score   Error  Units
DateFormatterBenchmark.parseJavaDate  avgt   30   813,562 ± 6,450  ns/op
DateFormatterBenchmark.parseJodaDate  avgt   30  1091,707 ± 7,008  ns/op

I also played around a bit with the benchmark using parseJoda for joda, but there are no real runtime changes.

[elasticmachine]

Pinging @elastic/es-core-infra

[spinscale]

@elasticmachine please retest this

[spinscale]

this requires more investigation, parsing seems to be broken, when using more than one parser, only the first one is applied correctly

[spinscale]

@elasticmachine retest this please

[danielmitterdorfer]

Looks fine overall, I left a few minor comments.

[spinscale]

thanks! applied your comments

[spinscale]

@elasticmachine retest this please

[danielmitterdorfer]

Thanks for iterating. Can you please rerun the microbenchmarks with the new changes and update the description? LGTM if Jenkins is also happy.

[spinscale]

there was no significant change in the benchmark stats, thus I didnt update

[rjernst]

LGTM