Replacement for #3099 and closes #3023

... and closes #4036

⚠️ Breaking: Removed EuiToggle & EuiButtonToggle

The EuiToggle component wasn't appropriately handling the accessibility of how a toggle should behave. It was replaced in EUI components with correct implementations and there's little to none usages outside of EUI, so it is safe to remove.

This PR also removes the EuiButtonToggle because it was using the EuiToggle component. Instead, we now support a quick addition of the appropriate aria-pressed via the isSelected prop on all our button components.

Upgrade path

• EuiToggle didn't come with any styles or other visual indications. Consider whether you're replicating EuiSwitch, EuiRadio, EuiCheckbox, or EuiButton (as a toggle) behavior and use the appropriate component.
• Simple EuiButtonToggle instances should be replaced with EuiButton. Moving label to be the children.
• If your EuiButtonToggle is of iconOnly, simply swap to using an EuiButtonIcon.
• If your EuiButtonToggle is of isEmpty , simply swap to using an EuiButtonEmpty.

All button replacements should address the toggle functionality in one of the two ways listed above:

1. If your button changes its readable text, via children or aria-label, then there is no additional accessibility concern.
2. If your button only changes the visual appearance, you must add aria-pressed passing a boolean for the on and off states. All 3 button types (will) provides a helper prop for this called isSelected.

Re-built the entire EuiButtonGroup component

The two main concepts brought over from #3099 are:

1. Use a <button aria-pressed="true or false"> for multiple selection groups

This is the preferred method for signifying whether a single button is on or off (pressed). Multi-selection groups are just a visually grouped button set all with their own state but under one legend.

2. Use a <input type="radio"> for single selection groups

Since only one button can be selected at a time for single selection groups, we make these behave as radio groups by actually using hidden radio groups. However, instead of trying to sync selection of a hidden input with the display, the element rendered by EuiButtonDisplay is a <label> connected to the input as is done in plain HTML.

Both of these button group types are established in the new EuiButtonGroupButton component since they share more props/similarities than differences so it's easier to maintain.

3. Additional required props

In addition to changing the actual buttons that are rendered, a few props are now necessary for the accessibility features to work properly.

• legend: Required to label the whole group with a single heading. Will be visibly hidden.
• name: Optional for single selections. Applies to the name attribute of the inputs to keep them grouped. This cannot be the same as legend because of naming collisions. Will generate an string by default.
• idSelected: Required for single selections because radio groups must have an option always selected.

Other (quick) changes

i. Added minWidth prop to EuiButton

There have been consumer situations where the min-width is not ideal and so this new prop allows consumers to quickly override this CSS property with an inline style.

ii. Added baseClassName to EuiButtonDisplay

Before, EuiButtonDisplay was only used by EuiButton which made it ok to hard-code the euiButton class, but now it's being used directly by EuiButtonGroupButton which wanted to provide it's own base class that all the variations are built on.

EuiButton still produces all the same class lists it did before, but now EuiButtonDisplay is just more reusable (but still for internal use only).

iii. Updated EuiButton disabled styles to be based on a class and not :disabled

Because EuiButton can now render as something other than a <button>, we want to ensure that the disabled styles are applied, so the mixins now are based on .euiButton-isDisabled instead of :disabled.

Checklist

• Check against all themes for compatibility in both light and dark modes
• Checked in mobile
• Checked in Chrome, Safari, Edge, and Firefox
• Props have proper autodocs
• Added documentation
• Checked Code Sandbox works for the any docs examples
• Added or updated jest tests
• Checked for breaking changes and labeled appropriately
• Checked for accessibility including keyboard-only and screenreader modes
• A changelog entry exists and is marked appropriately