Fixes #27084: Enforce UTC timezone for datetime

[fanf]

https://issues.rudder.io/issues/27084

Enforcing UTC for DateTime and first step toward using java.time.Instant internally.

This PR is three folds:

• first, it port https://github.com/Normation/rudder/pull/6452 to Rudder with an issue number. Its goal was enforcing the internal timezone of parsed datetime as UTC.
• second, it adds a lot of the same everywhere, because once we start to break from JVM default somewhere, we must used the same everywhere, else all comparison (equals relative to date time) break.

That last part was very unsatisfying, because once we have DateTime.now(DefaultTimeZone.UTC) everywhere, we are just mostly using Instant. In modern Java, an instant is represented in string as exactly that: an ISO/RFC3339 date time string with the UTC (Z) timezone.

So :

• third, it brings a proof of concept of changing DateTime in business object to Instant, and it works quite well. Most of our code is semantically using Instant and not really DateTime, so for most part, it's easy. So remarks follow.

Migrating to Instant as a default

We should use Instant for all our internal time representation, and just use ZoneDateTime at the periphery of businss code safe for very specific case like (date based) schedulers.

Bonus: it's an easy path out of joda.time.

To ease that migration:

• I created a parser for Instant that is more lenient than the java standard one and accept timezones (actually fallback to parsing as a ZonedDateTime and convert to Instant)
• there is a couple of helpers methods in DateFormatService that help translate between the different types.

[fanf]

PR updated with a new commit

[fanf]

Actually, it breaks in subtil way lot of things (esp regarding node queries / report comparison / etc). Which means they are already broken, but that change is not enought to unbroke them.

[fanf]

PR updated with a new commit

[fanf]

PR updated with a new commit

[fanf]

OK, merging this PR