[Button] Add a shared kind for input-control actions

Is this something you or your team is interested in contributing a pull request towards?

None

Expected Behavior

Buttons embedded within input controls should use a shared semantic Button kind, provisionally inputAction, so their appearance and interaction states are defined consistently in one place.

The proposal should determine:

• Which controls belong to this category. Initial candidates are TextInput copy and password visibility, DateInput copy and calendar trigger, TimeInput clock trigger, and DateTimeInput calendar trigger.
• Whether Calendar navigation and Select clear actions have the same semantics or should remain separate.
• How square geometry and alignment with the input height are enforced across input and icon sizes.
• The expected focus, hover, disabled, and open/active states.
• How base, HPE, and custom themes define the shared kind.
• Whether Button should recognize an explicitly configured string kind when theme.button.default is absent.
• How existing dateInput.button.margin, dateTimeInput.button.margin, and timeInput.button.margin theme properties should be deprecated or migrated.

Component implementations should consume the shared definition rather than duplicating padding, radius, and state styling or exposing separate button theme objects for each input component.

Actual Behavior

Input-control buttons are styled independently:

• TextInput’s read-only copy button uses a local styled Button with input padding and the global control radius.
• TextInput’s password visibility button uses kind="toolbar".
• DateInput reuses the copy button for readOnlyCopy, while its calendar trigger is a plain Button with component-specific margin.
• TimeInput uses its own styled Button following the copy-button pattern.
• DateTimeInput uses a plain Button with component-specific margin.

This duplication allows the controls to differ in sizing, radius, focus, hover, disabled behavior, and theme support over time.

URL, Screenshot, or CodeSandbox

Follow-up to #8104, identified during review of PR #8117.

Relevant discussion:

• Proposal to avoid component-specific input-button theming
• Discussion of a shared Button kind
• Developer-experience and consistency rationale

Steps to Reproduce

1. Open the TextInput read-only copy/password, DateInput, TimeInput, and DateTimeInput stories.
2. Inspect the Button rendered at the edge of each input.
3. Compare their Button kind, padding, radius, margin, focus, hover, and disabled styles.
4. Observe that these styles come from separate component implementations and theme properties rather than one shared semantic definition.

Your Environment

• Grommet 2.56.1
• Browser: Not applicable (theme API proposal)
• Operating System: Not applicable