[Feature Anywhere] Introduce a new Feature-Anywhere plugin

[ohltyler]

The ongoing Feature Anywhere project introduces several new components and generic interfaces that will be used by external plugins that want to integrate into the workflows (e.g., AD plugin displaying anomalies on a particular line visualization). And, while the current scope of this project is to only support integration with visualizations, the larger vision is to support future integrations with other Dashboards objects, such as Dashboards or Observability charts.

So, to maintain all of the feature-anywhere-related components, we can introduce a standalone plugin that lives inside of core Dashboards. The primary purposes of this plugin are to:

1. Register and maintain a feature-anywhere saved object type
2. Register and maintain a feature-anywhere expressions function type
3. Maintain generic overlay interfaces (currently scoped to line chart visualizations)
   4. Maintain generic UI components that plugins can extend
4. Provide a central location for documentation on the project and how plugins can utilize its framework

Point 4 may not be utilized much for the initial release of Feature Anywhere. The main idea is that as plugins integrate into this framework, and as customers provide feedback on the most productive workflows, we can develop more common/shared workflows that can use the same generic UI components. This may include components related to the plugin options in the visualization options menu, performing different CRUD operations on such plugin resources, or toggling overlay data for that plugin on a visualization.

[KrooshalUX]

Let's connect on #4 a bit more to see what could or should be generalized to be created or supported within OUI. Generally UI components or compositions of existing primitive from EUI/OUI should be utilized as much as possible vs new, custom patterns.

@kgcreative for visibility

[ohltyler]

@KrooshalUX as of now we don't have any concrete ideas on what components/workflows makes sense (if any) that would be generalizable to store in core Dashboards. Our initial approach is to implement both AD and Alerting separately, and then regroup later to see if there is some common enough items that could be abstracted away, such as a plugin resource creation flow. I definitely get your point to use OUI as much as possible.

The main purpose of that comment is that if we encounter such a situation, this separate plugin will be a logical place to store such components.

[ohltyler]

@KrooshalUX as an update, for this initial release we don't plan on having any generalizable components/workflows that would be persisted here. I will remove Point 4 for clarity.