feat: add simple transfer component

[flaminic]

Implements LIBS-574

Storybook demos here.

---

Description

Adds an accessible version of the transfer component.
This component differs from the transfer component because in this new version the transfer option ui can not be customised. This choice implies that the new component was be rewritten using a select with options, providing accessibility for free and also simplifying the code.
Either than that, there should be almost no difference between the old and the new component. I say almost, because the color of an option when highlighted also changed. Now we use the default color for select/options, where customisation is not even possible (unless with very weird hacks).

Checklist

• API docs are generated
• Tests were added
• Types added / updated
• Storybook demos were added

---

Screenshots

[dhis2-bot]

🚀 Deployed on https://pr-1626--dhis2-ui.netlify.app

[Topener]

Great job on the docs & demos! Once merged it should automatically be deployed to the developer portal as well and show up at the web components section there.

I cannot review the rest of the PR so I won't leave a review here :)

[amcgee]

Can we replace Transfer instead of creating a new component here? Do we know of specific cases (maybe @dhis2/analytics-frontend) where we're using the removed customization options in the existing transfer?

[Mohammer5]

Generally looks good to me!

I think the 4 buttons could use a aria-label to describe what they're doing, using i18n so we have proper translations

[Mohammer5]

Not needed anymore, I guess

[flaminic]

Can we replace Transfer instead of creating a new component here? Do we know of specific cases (maybe @dhis2/analytics-frontend) where we're using the removed customization options in the existing transfer?

@amcgee yes we can do that. I think in the meeting we discussed marking the current transfer as deprecated first, to give some time for people to move if they need to. I'm happy with both solutions. If we want to go for the second one, i won't merge but will figure out how to mark it as deprecated first, and can add it to this PR. What do you think is best?

[Topener]

I agree with @amcgee here to upgrade the old one instead of introducing a new component as a replacement. Having both is more confusing for developers than a breaking change upgrade. One small addition to this page could be enough: https://developers.dhis2.org/design/help/migrating

[Mohammer5]

@amcgee: Can we replace Transfer instead of creating a new component here?
@flaminic: in the meeting we discussed marking the current transfer as deprecated first, to give some time for people to move if they need to
@Topener: I agree with @amcgee here to upgrade the old one instead of introducing a new component as a replacement.

	Adding a new component	replacing the old component
Benefits	Devs can upgrade the library to use unrelated changes	Devs will know which component they can use without having to read documentation (they do have to read docs anyway to know the differences between the old/new component)
Trade-offs	Potentially confuses developers, they'll have to read documentation	Devs can't upgrade the library without also upgrading all transfer use-cases

My opinion on this is:
We should trust the developers to be able to read documentation if and when they're confused, rather than trying to prevent that.
It could have a much worse impact - also on our teams - when being forced to do a certain change when you actually want something completely different. I'm not sure how widely the transfer component is being used (with the select component, this would be quite a severe change), but I'm certain it has some advanced use-cases.

I wouldn't be worried about devs being confused as long as we clarify things in the docs. But I'd be worried about forcing library users to be forced to do work when they want a completely different change. Especially with a proper deprecation notice, devs would know that they're using the wrong component if they chose the old one due to confusion.

[Topener]

So I rechecked the docs, and it seems there are functional changes to this component and the transfer component. But as you indicated the Transfer component will be deprecated, we'd need to write a migration guide away from the transfer component as well. In that case, an override is not needed and it can be released as-is (per this PR).