Remove or downplay ui_metrics in usage collection README

[alexfrancoeur]

While we're waiting on a solution to better handle ui_metrics I think we should remove, de-emphasize or blatantly warn that the output of collecting your data that way offers no pragmatic way to analyze the data.

We have a warning at the bottom of the documentation, but it's not nearly in your face enough. https://github.com/elastic/kibana/blob/master/src/plugins/usage_collection/README.md

The only caveat is that it makes it harder to consume in Kibana when analysing each entry in the array separately. In the telemetry team we are working to find a solution to this. We are building a new way of reporting telemetry called Pulse that will help on making these UI-Metrics easier to consume.

I feel like I'm constantly telling folks to not use ui_metrics due to the way it's outputted, but teams still continue to implement. I'm wondering if it's because it has so much representation in our collection docs. When this happens, it puts us in a tough position saying that the key / value pairs are there, but you can't do anything with them. Teams end up expecting ui_metrics to collect all the data that's important to them, but then when we release, they can't actually use it in any meaningful way.

[elasticmachine]

Pinging @elastic/pulse (Team:Pulse)

[TinaHeiligers]

@afharo perhaps you can add this to your PR for moving the collectors out of the telemetry plugin?

[afharo]

I'm happy to do any changes in the documentation. But I think it can be done in a separate PR. I don't want the other PR to be held only because we cannot find the right wording to downplay the ui_metrics.

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)