Standalone field list component

[flash1293]

A filterable list of selectable fields with detailed information about each field is something which is could be re-used in various apps to avoid redundant implementation of very similar features and inconsistencies between apps. Lens and Discover are two apps where this is currently an opportunity because both are currently (re)-written.

The "FieldList" component should be provided as a plugin like the query/filter bar component in the data plugin and be configurable enough to be used in various places (also beyond Lens and Discover, maybe SIEM or ML could also use such a component).

Open questions:

• Does this even make sense? Or does the coordination overhead cancel out the advantages here?
• Should the field list take care of data fetching (e.g. for top values and metric popovers)?
• Where should such a component live and who takes ownership?
• What features are necessary? What features would be nice to have?

Related: #39798

[elasticmachine]

Pinging @elastic/kibana-app

[cchaos]

From a completely UI perspective, I think it very much does make sense to make these re-usable. I don't have all the answers to your bullet points and it may be a full "Analyze" team ownership. But as we are already seeing the want to align the Lens and Discover fields lists, there's already a huge win to do this for both applications. In the future, I could see Graph or Security interested in using this mechanism as well. Since I helped design the thing, I can help make it reusable too, just LMK

[ghudgins]

would be good to consider this as part of a broader project between lens / discover as tools for adhoc data exploration (re-using the field list between both views of the data)

[jughosta]

Implemented via #137779