feat(date-time-picker): added precision and value interactions

[mizgaionutalexandru]

Description

Precision and value interactions

Previously, the DateTimePicker had a property named timeGranularity. This PR changes its name to precision and adds the day option to hour | minute | second.

The image below explains the different interactions between the precision property and the most specific type of the date value props (min, max or value).

A few examples:
If there is a date value prop (min, max or value) provided, the default precision will change to accomodate said prop. For example, if CalendarDate is provided but the precision isn't, the default precision will be day. If the type provided is CalendarDateTime or ZonedDateTime, the default precision will be minute.
If the precision is provided by the consumer it shouldn't be overridden. etc.

Note

These will all be included in the final documentation of the component in some way

Other changes

• now the value clears if only the interval changes
• fixed some ZonedDateTime edge-cases
• tests now include assertions for the date value props types (checks for CalendarDate/CalendarDateTime/ZonedDateTime)
• improved unit tests readability in DateTimePicker as well as Calendar source files by removing unnecessary describe groupings and changing the test functions' titles to be more descriptive

Related issue(s)

• [Feat]: Add Date Picker Pattern #2559
• [Feat]: Add Calendar pattern #2560

Motivation and context

This change gives the consumer more flexibility on the type of objects can be used to represent dates and makes sure that all of them aligns and interacts accordingly with the precision property and its new option. Also, the effort to improve tests readability will prove beneficial in any future development/debugging sessions.

How has this been tested?

Unit tests.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Chore (minor updates related to the tooling or maintenance of the repository, does not impact compiled assets)

Checklist

• I have signed the Adobe Open Source CLA.
• My code follows the code style of this project.
• If my change required a change to the documentation, I have updated the documentation in this pull request.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.
• I have reviewed at the Accessibility Practices for this feature, see: Aria Practices

Best practices

This repository uses conventional commit syntax for each commit message; note that the GitHub UI does not use this by default so be cautious when accepting suggested changes. Avoid the "Update branch" button on the pull request and opt instead for rebasing your branch against main.