Support yaml as metrics file

[dmpetrov]

Yaml is one of the most used file format. We need to support it for metrics.
More details: #3409 (comment)

ToDo:

• update docs

[dmpetrov]

Ideally, as part of this issue a few other steps should be implemented from the link above:
[2] Add support for YAML since it is an often-used format - #3393 (comment)
[3] With two simple json/yaml formats, do we really need raw format? Let's get rid of raw metrics format.
[4] Do we really need xpath in dvc-files? I see a clear use case in metrics show as a filter but not in other commands. Let's consider removing XPath (from metrics files).
[5] Metrics type was mostly used for distinguishing xpath algorithms between hierarchical json and flat csv/tsv/hcsv/htsv. It looks like it is not needed if only json/yaml left. Let's remove metrics type.

[efiop]

@dmpetrov So maybe let's get rid of raw, *sv support, drop explicit XPath and type, support only yaml (could leave json, but is there really a point?) and pretty much do the same thing that we do with params? E.g.

dvc run -m all.AUC ... # will assume metrics.yaml, similar to how we assume `params.yaml`
dvc run -m custom_name.yam:all.AUC ...

?

And -m won't even mean that metrics.yaml is considered an official output cached by dvc. -M will be simply gone in that case. So a usual workflow would be to keep that metrics file in git or not commit it at all, even. These are just things from the top of my head, not sure if this is the way to go.

[dmpetrov]

@efiop agree re the format support (but I'd keep json). The good news is - both yaml and json are hierarchical and we can use the same patterns for filters (like path).

Granular metrics addressation (like -m all.AUC) seems a bit too complicated scenario. It has one advantage - multiple stages can append metrics to the same metrics file. But this metrics appending is not easy to implement. We can think about this feature when we have more demand for such scenarios.