[Amsterdam] New tab styles

[daveyholler]

Summary

Introduces new tab styles for the Amsterdam theme.

Checklist

• Check against all themes for compatibility in both light and dark modes
• Checked in mobile
• Checked in Chrome, Safari, Edge, and Firefox
• Checked in Kibana within existing apps
  - [ ] 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

Special Attention

There will be some instances that require special attention when migrating in Kibana.

1. Solutions (like Observability) that use tabs as navigation will need to address some CSS overrides.

2. [Discuss] Use cases where tab content with a shaded background is adjacent to the tab bar will need a spacer or margin.
   

[kibanamachine]

Preview documentation changes for this PR: https://eui.elastic.co/pr_4075/

[cchaos]

Thanks as always @daveyholler for getting this one started. It makes it a ton easier to see the implications of the update.

My two concerns are that it can (1) easily degrade appearance as you pointed out it some usage examples. And (2) it now emphasizes all versions of the tabs which may not be the intention.

1. Most consumers have placed the tabs with the assumption it contains a border and no rounded corners

Places like in a flyout header or sidebar where they act as a divider will no longer work. Or where content buts up against to feel like it's a localized container to the content of the tabs (you showed an example from the EUI docs).

2. The new emphasis on all versions may have adverse affects

Take for example when there are multiple tabs in a page layout (like this new one for Fleet), The only difference between the tab versions is boldness and/or font-size creating a bit of conflict in hierarchy.

---

From my understanding of where this style was originally developed, was in context of using it as a more emphasized version of the "condensed" style for in-app navigation. This makes 100% sense to me. Therefore I propose, we update to this style only in the condensed version (which I think we can name better). So then we have a bit better of a hierachy like:

I propose that ^^ ... Haha sorry

[johnbarrierwilson]

At a low-level, I think the gray box looks great within the new Amsterdam styles. But, @cchaos raises some really good points.

Opinion: across the world wide web, tabs have always played the role of minimal-style navigational elements. Adding a large box around them changes the nature of tabs themselves.

At a high-level, I agree that it works okay in the navigation, but with the new solution sidenav possibly coming up, I'd suggest pressing pause on this until we come to a decision on the solution sidenav. Ultimately, if solution sidenav project comes up with an element that would replace all navigation like this, then it would change the outcome of this PR's update.

[cchaos]

I'm going to throw this one back into draft mode until we have a path forward.