Reduce allocations for JSON and logfmt parser

[jeschkies]

What this PR does / why we need it:
The JSON and logfmt parsers suffer from a high number of allocations when the parsed labels have a high cardinality.

This change reduces the allocations quite a bit by copying the labels bytes to a byte buffer.

Note: The benchmarks ran without a validation step that calls LabelResult.Labels() as that method uses a lot of allocation but is used only once in production code.

go test -bench Benchmark.+HighCardinality -count=10 -benchtime=10s -memprofile=mem.prof -run=^$
                               │ base_no_validation.log │       new_no_validation.log        │
                               │         sec/op         │   sec/op     vs base               │
JSONParserHighCardinality-16                245.1m ± 1%   227.9m ± 4%  -7.02% (p=0.000 n=10)
LogfmtParserHighCardinality-16              447.7m ± 2%   415.7m ± 3%  -7.15% (p=0.000 n=10)
geomean                                     331.3m        307.8m       -7.08%

                               │ base_no_validation.log │        new_no_validation.log         │
                               │          B/op          │     B/op      vs base                │
JSONParserHighCardinality-16               48.81Mi ± 0%   37.33Mi ± 0%  -23.51% (p=0.000 n=10)
LogfmtParserHighCardinality-16             69.48Mi ± 1%   46.39Mi ± 0%  -33.24% (p=0.000 n=10)
geomean                                    58.23Mi        41.61Mi       -28.54%

                               │ base_no_validation.log │        new_no_validation.log        │
                               │       allocs/op        │  allocs/op   vs base                │
JSONParserHighCardinality-16               1323.9k ± 0%   608.2k ± 0%  -54.06% (p=0.000 n=10)
LogfmtParserHighCardinality-16             1848.0k ± 0%   215.4k ± 0%  -88.34% (p=0.000 n=10)
geomean                                     1.564M        361.9k       -76.86%

Special notes for your reviewer:

Checklist

• Reviewed the CONTRIBUTING.md guide (required)
• Documentation added
• Tests updated
• Title matches the required conventional commits format, see here
  • Note that Promtail is considered to be feature complete, and future development for logs collection will be in Grafana Alloy. As such, feat PRs are unlikely to be accepted unless a case can be made for the feature actually being a bug fix to existing behavior.
• Changes that require user attention or interaction to upgrade are documented in docs/sources/setup/upgrade/_index.md
• If the change is deprecating or removing a configuration option, update the deprecated-config.yaml and deleted-config.yaml files respectively in the tools/deprecated-config-checker directory. Example PR

[jeschkies]

This method should ideally go. It's used only once AFAICT