De-couple panel action logic from UI

[stacey-gammon]

We want actions to be available for any Embeddable, but we don't want to force the embeddable object to come with the chrome that it does in dashboard panels. Think of how Canvas works - actions show up in a right column, not a context menu pop up. If we use Embeddables inside Canvas, we want any available actions to also be exposed inside Canvas - and that means decoupling it from the UI so any container can decide how to expose those actions (either via a context menu, or via some other mechanism).

So we should have both a pluggable actions registry, and keep the panel actions registry separate. At which point, it becomes an interesting question... do we need a panel actions registry at all, or do we dynamically create the panel actions menu from the actions, simple mapping something like menuItem.onClick to action.execute? And menuItem.isVisible to action.supports(Embeddable). We'd have to think about how isVisible and isDisabled work, especially since there is a use case for not knowing whether something will support a given embeddable at any given time. Maybe we need another function like action.canExecute(Embeddable) to determine enabled vs disabled state.

[elasticmachine]

Pinging @elastic/kibana-app

[joelgriffith]

Related: #26476

[ppisljar]

Thank you for contributing to this issue, however, we are closing this issue due to inactivity as part of a backlog grooming effort. If you believe this feature/bug should still be considered, please reopen with a comment.