feat: Allow props prefixed by "data-" to be rendered as attributes in picker's option elements

[cgmonte]

Jira tasks

Main task: https://liferay.atlassian.net/browse/LPD-32878
Sub-task: https://liferay.atlassian.net/browse/LPD-35826

Introduction

The main Jira ticket above is a Liferay's DDM Form task to add data-option-reference attributes to option elements in Form's DOM.

It worked without having to modify Clay in all of the following Form field types: Grid, Multiple Select, Single Select and Multiple Select from List, which is not yet merged.

But the Single Select from List field type did not work because, currently, Option's props are specifically destructured, without assigning remaining props to something like an otherProps object.

Goal

This PR seeks to allow props prefixed by "data-" to be rendered as attributes in picker's option elements.

Issues

While developing, after allowing other props to be passed down to option elements, not only the data-option-reference attribute was rendered, but also a index appeared in the option. This happens because useCollection() adds that to DynamicCollection items. To prevent that, which did not seem right, a filter was added to otherProps to programmatically remove object keys not starting to "data-". A unity test was added to check for this case as well.

[matuzalemsteles]

@cgmonte thanks for the contribution.

[cgmonte]

Hey @matuzalemsteles, I have pushed a new version. I have excluded both the type declaration, because of what I described here, and the runtime filter you mentioned here. Problem is: because useCollection() adds an index prop that is passed together with the added otherProps, snapshots had to be updated. This will break other unity tests based on snapshots in the Portal as well.

[cgmonte]

I don't think this is the final solution, and having that index in the DOM doesn't seem right. It wasn't meant to be there. But I am sending this so we can discuss other options.

[matuzalemsteles]

I sent a commit to remove the index from the DOM is safe now. We use it internally to calculate other things and the component needs to ignore them.

Well, regarding JS, I don't consider runtime prop validations in components to be very useful. It won't help much, even when passing the wrong value. That's why we avoid it for components nowadays. It doesn't have a valuable benefit, especially when TS is used more today and we also want people in DXP to use TS more than JS. In this specific case, I still don't think we need validation.

[matuzalemsteles]

LGTM