reset the basemap when the labelsbuilder is reset

[MasslessParticle]

This PR fixes an issue where the label_format stage sometimes doesn't populate labels when it should.

The label baz exists on all log lines but is only populated on the first line.

The issue is this call to IntoMap. It tries to avoid copying the map multiple times here but the baseMap variable isn't reset when the labels builder is reset. As a result, calls to to IntoMap after the builder has been reset mean that !b.hasDel() && !b.hasAdd() && !b.HasErr() evaluates to true but b.baseMap == nil also evaluates to true so no items are copied.

This PR makes it so that b.baseMap is reset along with the rest of the builder's state in Reset

[MasslessParticle]

I also moved this out of the guard because consecutive calls to IntoMap turned out to also fail in addition to calls after Reset

[cstyan]

I'm unsure of this change. I don't know if the intention of the builder and baseMap was that we only build a labelset once and then always return it, or if there are cases where we should allow different label sets to be passed to the same builder without calling Reset. I think only the latter would require these lines to move.

[MasslessParticle]

Without that change, this test fails:

	t.Run("it can copy the map several times", func(t *testing.T) {
		b := NewBaseLabelsBuilder().ForLabels(lbs, lbs.Hash())

		m := map[string]string{}
		b.IntoMap(m)

		require.Equal(t, map[string]string{
			"namespace": "loki",
			"job":       "us-central1/loki",
			"cluster":   "us-central1",
			"ToReplace": "text",
		}, m)

		m2 := map[string]string{}
		b.IntoMap(m2)
		require.Equal(t, map[string]string{
			"namespace": "loki",
			"job":       "us-central1/loki",
			"cluster":   "us-central1",
			"ToReplace": "text",
		}, m2)
	})

I'd sort of expect to be able to make any number of copies of the map as long as I'm aware of what I'm passing.

[cstyan]

discussed on slack, I had my own code mixed up and was misunderstanding the use case and change here