tp stats: introduce "ftrace_cpu_has_data_loss" and downgrade severity of "ftrace_cpu_overrun_delta"

First step on the road to more actionable trace quality reporting in the
UI. Starting with the fact that "ftrace_cpu_overrun_delta" doesn't make
sense for RING_BUFFER traces - the delta is between the start-of-trace
and the final flush, whereas the data remaining in the perfetto ring
buffer will usually cover just the last N seconds of that time frame.

traced_probes already sets a special ftrace_event_bundle.lost_events
marker in traces when it gets told by the kernel that the kernel buffer
overran between userspace reads. So if any such packets are part of the
final trace, care needs to be taken when interpreting the trace data.

Keeping it as a simple bool for now. I'll look into surfacing more info
(affected timestamp range) in the future.

Also explain why kDataLoss traced_buf_patches_failed isn't [usually]
that scary for DISCARD buffer traces. Better than no explanation for
now, but we should improve the actionability of the signal.

Change-Id: I9cf8718b4f05da28626ee44fa19ecca4dccf30dd