[int] Add non-deprecated UTC timezone utilities for discussion (Don't panic!)

[sfayer]

Hi All,

Related to #8607. Mentioning @martynia too. For discussion:

I'm not sure we really got to the crux of the timezone discussion at the ddev meeting earlier today: As I understood it, the main worry was that moving to timezone aware datetime objects everywhere is a massive job and likely to break everything: I agree, but that isn't what we were trying to propose.

The utcnow function is used in a lot of places: Sure, it's unlikely to actually be removed for from python any time soon, but we're still going to be getting deprecation warnings all over the place when python is updated (if the warnings aren't turned off by diracosrc? ;-)
What we are suggesting is to have our own set of functions that don't trigger the deprecation warnings but behave exactly the same as the old functions (still naive with no timezone set): These can then be used in place of the deprecated functions. Yes, it's a big change to replace utcnow() everywhere, but it's a mechanical find and replace with no behavioural change: This should be very low risk.

I've included some example functions in this PR so you can see what I'm talking about. (Maybe there will be some argument about exactly where this could live: I've deliberately not put it in DIRACCommon as the intention is that it's a shim to fix-up old DIRAC code rather than encourage use of naive datetimes in new code).

There are also about 12 (at an approximate count) places where there are subtle timezone related handling bugs in DIRAC which is where things like accounting plots being weird for an hour around timezone changes stem from: Those could be fixed up too, but it would be a separate phase 2.

We (Imperial) would do this work, we're not asking you to do any more than the PR reviews (and read my long descriptions about how we can do this safely in PRs ;-)

Regards,
Simon

BEGINRELEASENOTES
*Core
NEW: Add non-deprecated UTC timezone utilities
ENDRELEASENOTES