expfmt: Consider allowing empty MetricFamilies

Currently, a MetricFamily with no Metrics is invalid (i.e. it will never be created by encoders, and it will yield an error upon decoding).

As it turns out, client libraries that are ignorant of the protobuf exchange format are making use of empty metric families as represented in the text format, i.e.

# HELP blah some help
# TYPE blah gauge
# HELP blub another metric
# ...

This has never caused any trouble because the only entry point of the text format into the Prometheus universe is the text-format parser, which kicks out those metric families here.

@brian-brazil thinks empty metric families is something we should allow in general. That would require to change all code encoding and decoding protobuf, including the text-format parser. (Ideally, all that code is only in expfmt but there might be legacy.) Also, consumers of decoded protobuf have to be checked to deal gracefully with empty MetricFamilies, as they were so far guaranteed to not appear.

Start in expfmt, including the text-format parser at text_parse.go and the protobuf encoding and decoding paths. Trace how empty MetricFamilies are currently rejected, then check consumers of decoded protobuf for graceful handling. Done means empty families are accepted consistently across text and protobuf formats without breaking existing behavior.