Parseable Looking Timestamps cause Stack Traces in Allure Report Generation

Junit output generated by cpputest do not contain nanoseconds or a timezone. Eg:
```

...
```
Such lines cause this error in Allure STDOUT/STDERR:
```
Parsing file unittests/cpputest_mytest.xml
Could not parse time 2022-05-16T08:06:10 using parser io.qameta.allure.datetime.ZonedDateTimeParser@3cdf2c61
java.time.format.DateTimeParseException: Text '2022-05-16T08:06:10' could not be parsed at index 19
at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052)
at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1954)
at java.base/java.time.ZonedDateTime.parse(ZonedDateTime.java:600)
at io.qameta.allure.datetime.ZonedDateTimeParser.getEpochMilli(ZonedDateTimeParser.java:30)
at io.qameta.allure.datetime.CompositeDateTimeParser.getEpochMilli(CompositeDateTimeParser.java:46)
at io.qameta.allure.junitxml.JunitXmlPlugin.getUnix(JunitXmlPlugin.java:171)
at io.qameta.allure.junitxml.JunitXmlPlugin.parseTestSuite(JunitXmlPlugin.java:161)
at io.qameta.allure.junitxml.JunitXmlPlugin.parseRootElement(JunitXmlPlugin.java:138)
at io.qameta.allure.junitxml.JunitXmlPlugin.lambda$readResults$0(JunitXmlPlugin.java:124)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at io.qameta.allure.junitxml.JunitXmlPlugin.readResults(JunitXmlPlugin.java:124)
at io.qameta.allure.ReportGenerator.lambda$readResults$0(ReportGenerator.java:47)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at io.qameta.allure.ReportGenerator.readResults(ReportGenerator.java:47)
at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197)
at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682)
at io.qameta.allure.ReportGenerator.generate(ReportGenerator.java:69)
at io.qameta.allure.ReportGenerator.generate(ReportGenerator.java:58)
at io.qameta.allure.Commands.generate(Commands.java:102)
at io.qameta.allure.CommandLine.run(CommandLine.java:160)
at java.base/java.util.Optional.orElseGet(Optional.java:364)
at io.qameta.allure.CommandLine.main(CommandLine.java:92)
```
These errors don't prevent the report being generated, but presumably the times in it will be incorrect/missing.

**Expected behavior**

Allure seems to output a nicely formatted error message, but the stack trace seems unnecessary (and smells of something that's not been handled - which isn't the case here).

The odd thing is the unit tests you already have seem to include a date of this exact format. That presumably works, so I couldn't figure out why this Junit causes problems. The dates here look perfectly parseable, so I'd expect Allure to be able to do so.

**To Reproduce the Issue**

Here is some anonymised junit:
```

```
My config looks like this:
```
plugins:
- junit-xml-plugin
- packages-plugin
```
And I run allure with this:
```
allure -v generate --config ./config.yml -c -o output unittest
```

**Environment**

| Allure version | 2.17.3 |
| --- | --- |
| Operating system | Ubuntu 20.04 |
| Test framework | cpputest |
| Generate report using | allure cli |

**Additional context**

This may or may not be useful. I've worked around the problem by "fixing" the dates in the XML before letting Allure run. In the process of doing this, I found the Allure unit tests on the subject, and the ticket https://github.com/allure-framework/allure2/issues/1011. I was probably doing something wrong, but converting timestamps from `2022-05-16T08:06:10` to `2022-05-16T08:06:10.000000` didn't seem to work either (despite another unit test for this same format) - the only solution I could find that did work was `2022-05-16T08:06:10.000000Z` or `2022-05-16T08:06:10Z`.

Start with ZonedDateTimeParser, CompositeDateTimeParser, and JunitXmlPlugin, using the stack trace to follow timestamp parsing during JUnit XML processing. Compare the existing date unit tests with the timezone-less timestamp shown here. Done means report generation handles this input without an unnecessary stack trace and preserves the timestamp information appropriately.

Written by the indexing model from the issue text.