[Security Solution][POC] Migrate Sourcerer component to Ad-hoc data views

[YulNaumenko]

Currently all the data view management in security_soluition is organized with Sourcerer component and sourcerer API

Problems we are trying to solve by migrating to Ad-hoc Data Views:

1. Resolve performance bottleneck related to uncached requests for ES fieldsCaps to check the indices availability.
2. Inability to define the page persistent data view with index patterns, which are used by the page components (network, hosts, user pages, etc). Documented GH issue. This cause another performance decreasing by fetching unnecessary data.
3. Minimize the data amount for the index fields fetching.
4. It currently includes the alerts index, which means users can't use this data view in rule creation without creating alerts on alerts
5. Separating out the alerts index would remove all the polling logic sourcerer currently has

Potencial blockers:

1. Ability to create the predefined data views (persistent and in-memory?) for security_solution without the user interaction. This logic also have the dependency to the current integrations state. If there is no integrations we shouldn't create data views and create it right after the user added security integration.
2. Ability to show in UI the disabled index aliases which are default for security but doesn't have indices yet.
   
3. Ability to show the index field description in the FieldBrowser component. Currently we are reading all that information from the file with BeatFields constant, which is updated manually.
4. Make data view readonly, to pre-event adding prohibited indices for the Detections pages:
   
5. Check with UX if this will be a similar user experience when we replace checkbox "Show only detection alerts" for the timelines page with the proper (in-memory?) Ad-hoc data view?
6. Manage the legacy data views, with index patterns which was excluded from the default data view in 8.0.

Potential migration steps:

1. Investigate a possibility to replace sourcerer API with the direct dataView plugin API usage and Ad-hoc data views.
2. Replace existing Sourcerer UI component with Ad hoc data views.
3. Simplify the data flows across the components which is using sourcerer, keep the minimum number of React hooks responsible for create/update and read state from the store. Could be done independently of the ad-hoc data views work.