feat(#697): adds support to datetime question type

[latin-panda]

Closes #697

I have verified this PR works in these browsers (latest versions):

• Chrome
• Firefox
• Safari (macOS)
• Safari (iOS)
• Chrome for Android
• Not applicable

What else has been done to verify that this works as intended?

Why is this the best possible solution? Were any other approaches considered?

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Do we need any specific form for testing your changes? If so, please attach one.

What's changed

• Adds codec, client component and scenario tests
• Extracts common code for reusability (CSS and composable)
• Remove unused code in XPath and clean up datetime constants in the common package.

[changeset-bot]

🦋 Changeset detected

Latest commit: 7f2b282

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 5 packages

Name	Type
@getodk/xforms-engine	Minor
@getodk/web-forms	Minor
@getodk/scenario	Patch
@getodk/common	Patch
@getodk/xpath	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[latin-panda]

@garethbowen Could you please take a look when you have some time? :)

[garethbowen]

Great work. Tested briefly in Firefox and Chrome and looks great.

I hate to leave no comments so I spent a few minutes coming up with something to say... The only thing I can think of is there's quite a lot of duplication between InputTime, InputDate, and InputDateTime. If there was a bug/improvement made in one it's quite likely I would forget to update the other two to match so they may drift. What do you think about merging them into one file with conditions where needed?

[latin-panda]

What do you think about merging them into one file with conditions where needed?

I considered merging the components, but decided to extract the core logic into useDateTimeInput.ts instead, we could probably extract a bit more, like that null check. The three components are actually small (< 50 lines each), and merging them now would likely lead to extra union types and extra conditionals throughout the scripts and templates. To me it feels cleaner to keep three focused files rather than one complex one. We can definitely look into moving isDisabled from all question types into a common composable.

I still have two more features to build, so I’ll keep an eye on things. If the complexity starts to climb, we can look at extracting more shared logic from these inputs then.

[latin-panda]

The GitHub Actions seemed to be out of service or extremely slow to start (+15min). The second commit is just testing whether the CI is working.