Use []byte when reading postings offset table

[colega]

What this PR does

TL;DR: don't try to be too clever, compiler already is.

In a previous PR I changed the labels reading to use an unsafe string backed by the original buffer slice, and then copying those strings manually when needed to store them.

It happens that those optimizations already exist in the compiler, and looking up map[string([]byte{...})] does not allocate as string.

Actually, I was surprised because benchmarks look even better, with even less allocations than when using the unsafe string.

name                                old time/op    new time/op    delta
BinaryReader_LargerBlock/benchmark    1.13ms ± 2%    1.05ms ± 2%   -7.02%  (p=0.008 n=5+5)

name                                old alloc/op   new alloc/op   delta
BinaryReader_LargerBlock/benchmark     157kB ± 0%     127kB ± 0%  -19.22%  (p=0.000 n=5+4)

name                                old allocs/op  new allocs/op  delta
BinaryReader_LargerBlock/benchmark     1.32k ± 0%     0.69k ± 0%  -47.54%  (p=0.008 n=5+5)

Which issue(s) this PR fixes or relates to

Followup on #3397

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[colega]

It's interesting to note the overall improvement after the three PRs (#3393 #3397 #3436) for this:

name                                old time/op    new time/op    delta
BinaryReader_LargerBlock/benchmark    2.72ms ± 4%    1.05ms ± 2%  -61.34%  (p=0.008 n=5+5)

name                                old alloc/op   new alloc/op   delta
BinaryReader_LargerBlock/benchmark    1.70MB ± 0%    0.13MB ± 0%  -92.54%  (p=0.029 n=4+4)

name                                old allocs/op  new allocs/op  delta
BinaryReader_LargerBlock/benchmark     40.2k ± 0%      0.7k ± 0%  -98.27%  (p=0.008 n=5+5)