Revamp DICOM datetime

[jmlaka]

Please see this DicomDateTime rewrite that now can handle time zone aware and naive values. External FixedOffset values no longer required. some methods deprecated some methods documented to be not optimal use of API Breaking changes This should fix #452

Thank you !

[jmlaka]

Hello, @Enet4. Please check out this pull request.

My initial questions: Maybe the [PreciseDateTimeResult] struct name is too long ?

The corecrate now requires the "clock" feature for chrono library, I don't know if this is acceptable. It's needed for the default handling of an ambiguous DT range, where one time zone is parsed and the second one is missing.

Also, for different parsing behavior of this situation a PrimitiveValue:to_datetime_range_custom<T> was added. I'm not sure if you are ok with such addition.

I'm not sure if I deprecated some methods correctly ...

Thanks

[jmlaka]

I fixed the problems you mentioned. The DicomDateTime had methods, which, on second thought, were superfluous.

[Enet4]

I hope you don't mind, I added in a few more changes before merging. Here is the summary:

• Adjusted the documentation around parse_datetime_partial, parse_datetime, PreciseDateTime, and the ambiguous DT parsers.
• Readjusted the methods in PreciseDateTime to better reflect its nature as a sum type of chrono date-time values.
• Made a custom PartialOrd implementation for PreciseDateTime because the derived one would be misleading. Because of how PartialOrd is derived, it could occur 2024-03-01 00:00:00 +00 being larger than 2024-03-01 23:59:59, much to the surprise of its users, just because it had a time zone specified.
• Moved PreciseDateTime to live alongside the other DICOM date/time types.
• Added impl FromStr for DicomDateTime.

With this, I think we are ready to move forward. :)

[jmlaka]

Thank you very much for your added insight. Happy to help.