[Edit by @JasonStoltz]
Is your feature request related to a problem? Please describe.
Flyouts can currently be sized programmatically via a size prop.

This is useful because sizing needs can vary between use cases depending on the page and flyout content.

However, for some use cases, this can actually be limiting, as we can't always predict how much space a user will actually need in their workflow -- the size of dynamic content could differ between users as well as screen size and resolution. Their needs can even during their workflow as their focus shifts back and forth between the primary page content and the flyout content (in the case of a push-based flyout). Some examples include:

• The observability AI assistant -- "Sometimes the standard width we open the flyout with in Chat mode is too cramped to display chat content. At the same time being able to see the rest of the page where the flyout is opened in is beneficial to keep context"
• ES|QL -- "When users switch to ES|QL mode there's already a push flyout which would be convenient to adjust to the users need depending on the screen size"
• Discover -- Users rely on an inline view of document details whilst also viewing their document list. Their focus will shift back and forth between these two content areas and there is evidence of users actually trying and failing to resize inline document detail views.

Describe the solution you'd like
The ability for flyouts to be resizable should give users the ability to make adjustments that solve this issue.

The implementation could be accomplished by exposing a resizable prop for flyouts. If the resizable prop is set to true, then a flyout would be user-resizable.

This could be accomplished by adding an EUIResizableButton to the flyout. Here is a POC that illustrates this: https://codesandbox.io/s/thirsty-noyce-4gxycf?file=/demo.tsx

This prop could be applied to any flyout (not just "push-based"). The default would be false. Would make the default false because there are a number things we want folks to consider before making their flyouts resizable. They are as follows:

• Responsiveness - Our responsive breakpoints usually rely on page width, not content width, so if a user resizes their flyout and then resizes their screen, it may cause some very awkward layouts. Users implementing a resizable flyout will need to account for this.
• Accessibility - [TODO: Fill in details]

These considerations should be clearly documented as guidance alongside the new prop in the EUI documentation.

Describe alternatives you've considered
An alternative to the resizable flyouts would be using an EUIResizablePanel. An example of this is illustrated in this POC. However, requires quite a bit more code to implement.

Another alternative would also be to just implement the EUIResizableButton on top of the existing flyout rather than integrating it as a feature of the flyout, as show in this POC. However, as this could/would be used in a number of places, I believe that it would be cleaner and more consistent to add this as a feature of EUI.

Desired timeline
"Sooner rather than later". Both AI Assistant and Discover have an immediate need for this. Do note though, that Discover has a workaround available to them in the meantime. My recommendation is by 8.13.

Additional context
#7290
via elastic/kibana#15901

[Original description by @timroes and @chandlerprall]
It would be nice, to have a resizeable={true} property on EuiFlyout, that will allow the user to resize the flyout by dragging its border.

### Tasks
- [ ] Create spec
- [ ] Implement in EUI
- [ ] Update EUI documentation (including guidance mentioned above)
- [ ] Update Figma