feat(core): action button

[coryrylan]

PR Checklist

Please check if your PR fulfills the following requirements:

• [x] Tests for the changes have been added (for bug fixes / features)
• [ ] Docs have been added / updated (for bug fixes / features)
• [ ] If applicable, have a visual design approval

PR Type

What kind of change does this PR introduce?

• [ ] Bugfix
• [x] Feature
• [ ] Code style update (formatting, local variables)
• [ ] Refactoring (no functional changes, no api changes)
• [ ] Build related changes
• [ ] CI related changes
• [ ] Documentation content changes
• [ ] clarity.design website / infrastructure changes
• [ ] Other... Please describe:

What is the new behavior?

https://61ba7ce549e858a779684d11--vmware-clarity.netlify.app/storybook/core/index.html?path=/story/components-button-action--page

• Action buttons are used internally and externally as part of our public API. They are used heavily in the datagrid api. This PR adds action button types as part of the upcoming datagrid work as well as refactors similar custom isolated icon buttons in the system. (form control actions, internal close buttons, accordion, treeview)

• Action button ensures consistency visually and for a11y with all icon actions in the system. This includes touch targets and interaction states

• This also refactors the base button class into isolated lit controller behaviors. This allows us to isolate component behaviors in a way that is composable and reusable in other components similar to mixins. Some of these controllers also are used in datagrid work that will be in followup PRs.

• The controllers do have internal docs/demos in storybook but I plan to add those as a stand alone PR to keep this one manageable.

Does this PR introduce a breaking change?

• [ ] Yes
• [x] No

Other information

[coryrylan]

@ashleyryan good callout! There are a couple of differences between the action and button components but potential opportunity to consolidate as well. The action button consolidates all the custom icon style buttons internally in the system like close, expand, and various control/form actions.

The cds-button has a lot of option/types that we would want to keep separate (for now). This includes visual options like statuses, sizes and loading. But primarily they have specific aria/a11y states like sorting, pressed/drag and expanded. If possible we try to avoid "impossible states" in the component APIs specifically with this case the a11y differences/complexities. I'm also hoping to avoid any "mega" components even if that means multiple derivative types.

However you got me thinking about a possible way to rename on the actions. I think I can rename the actions to better align with existing cds-button-* conventions and consolidate the API a bit with no breaking changes. I'll post back here and slack with what I find. Thanks!