release-22.1: improvements on timepicker

[maryliag]

Backport 1/1 commits from #81200 on behalf of @jocrl
Backport 1/1 commits from #81464 on behalf of @jocrl
Backport 1/1 commits from #81855 on behalf of @jocrl

/cc @cockroachdb/release

---

ui: Improve time picker keyboard input
Fixes #80655, mostly.

Previously, users had to type 1:03 PM (UTC) in order to enter text into the time picker.

This commit modifies the time picker so that users would instead type either

• 1:03, or
• 01:03

to enter text into the time picker. Copying and re-pasting the text from a time picker still works.

Release note (ui): The time picker component has been improved such that users
can use keyboard input to select a time without having to type " (UTC)"

---

ui: Add tests for the TimeScaleDropdown component
This commit splits out tests in timescale.spec.tsx and adds additional tests
for the TimeScaleDropdown component, including testing that the custom time
picker is initialized to the currently selected time. This also adds
TimeScaleDropdown stories.

Release note: None

---

ui: open TimeScaleDropdown directly to the custom menu when custom is selected

Fixes #78499

This commit modifies the TimeScaleDropdown so that if a custom time is currently
select it opens directly to the custom selection menu, and a "Preset Time
Ranges" navigation link to go to the preset options from the custom menu.

This commit also cleans up the unused DateRange component.

Release note (ui): The time picker now opens directly to the custom time
selection menu when a custom time is already selected. A "Preset Time Ranges"
navigation link has been added to go to the preset options from the custom
menu.

---

Release justification: low risk, high benefit changes

[blathers-crl]

Thanks for opening a backport.

Please check the backport criteria before merging:

• Patches should only be created for serious issues or test-only changes.
• Patches should not break backwards-compatibility.
• Patches should change as little code as possible.
• Patches should not change on-disk formats or node communication protocols.
• Patches should not add new functionality.
• Patches must not add, edit, or otherwise modify cluster versions; or add version gates.

If some of the basic criteria cannot be satisfied, ensure that the exceptional criteria are satisfied within.

• There is a high priority need for the functionality that cannot wait until the next release and is difficult to address in another way.
• The new functionality is additive-only and only runs for clusters which have specifically “opted in” to it (e.g. by a cluster setting).
• New code is protected by a conditional check that is trivial to verify and ensures that it only runs for opt-in clusters.
• The PM and TL on the team that owns the changed code have signed off that the change obeys the above rules.

Add a brief release justification to the body of your PR to justify this backport.

Some other things to consider:

• What did we do to ensure that a user that doesn’t know & care about this backport, has no idea that it happened?
• Will this work in a cluster of mixed patch versions? Did we test that?
• If a user upgrades a patch version, uses this feature, and then downgrades, what happens?

[cockroach-teamcity]

This change is