[COMPONENT] Create DateRange component

[ ] I have written a good issue

Describe the solution you'd like

There should be a date range component, that allows selecting a from and to date, but works as one input regarding validation and return value.

Implementation wise there are the following requirements:

[ ] Should use two Kirby form-field date internally, to get date selection out of the box
[ ] Should encapsulate and apply common validation for from and to date ie. to date can not be before from date.
[ ] Should work as a wrapper that content projects 2 date inputs as from and to date, such that the implementation details of the date components are accessible to be modified by the consumer.
[ ] Should provide a default from and to date implementation, such that content-projection is an enhancement not a necessity.
[ ] The component should internally wrap date components in form-fields, to avoid extra overhead for the user. By doing so, expose form-fields input properties as inputs to the component (label and message for now).
[ ] Component should be created as a custom input, implementing the control value accessor interface.
[ ] Return value should be an object, containing to and from date as separate string properties, with the possibility of adding state (i.e. valid/invalid when only one date is selected). The return values should follow ISO 2014, ISO8601 and HTML standards.
[ ] Component should be responsive

Business-logic wise there are the following requirements:

[ ] Should validate that from date is before to date
[ ] Should validate that both from date and to date are filled in
[ ] Should support setting error message and state (see "Error" section)

The implementation should account for the future enhancement of a custom date range picker, which will then replace the two separate native date pickers on date components when used in the context of date range component. E.g. a snake trail between from and to.

Have you considered any alternatives?

Currently two separate dates can be used, but we're not getting the shared validation and user experience from this solution.

Checklist:

The following tasks should be carried out in sequence in order to follow the process of contributing correctly.

Refinement

[ ] Request that the issue is UX refined; do not proceed until this is done.
[ ] Request that the issue is tech refined; do not proceed until this is done.

Implementation

The contributor who wants to implement this issue should:

[ ] Make sure you have read: "Before you get coding".
[x] Signal to others you are working on the issue by assigning yourself.
[ ] Create a branch from the develop branch following our branch naming convention.
[ ] Publish a WIP implementation to Github as a draft PR and ask for feedback.
[ ] Make sure you have implemented tests following the guidelines in: "The good: Test".
[ ] Update the cookbook with examples and showcases.

Review

Once the issue has been implemented and is ready for review:

[ ] Do a self-review.
[ ] Create a pull-request. If you created a draft PR during implementation you can just mark that as "ready for review".

[ ] Create component: date-range folder, ts, html, scss
[ ] Implement component
[ ] Implement unit tests
[ ] Write docs

(must have start & end label - must have start & end message)

kirbydesign / designsystem