scorch reuses Posting instance in PostingsIterator.Next()

With this change, there are no more memory allocations in the calls to
PostingsIterator.Next() in the micro benchmarks of bleve-query.  On a
dev macbook, on an index of 50K wikipedia docs, using high frequency
search of "text:date"...

   400 qps - upsidedown/moss
   565 qps - scorch before
   680 qps - scorch after

index/scorch/segment/segment.go

@@ -64,6 +64,10 @@ type PostingsList interface {
 }
 
 type PostingsIterator interface {
+	// The caller is responsible for copying whatever it needs from
+	// the returned Posting instance before calling Next(), as some
+	// implementations may return a shared instance to reduce memory
+	// allocations.
 	Next() (Posting, error)
 }
 

index/scorch/segment/zap/posting.go

@@ -115,6 +115,8 @@ type PostingsIterator struct {
 	locChunkStart uint64
 
 	locBitmap *roaring.Bitmap
+
+	next Posting
 }
 
 func (i *PostingsIterator) loadChunk(chunk int) error {
@@ -266,10 +268,10 @@ func (i *PostingsIterator) Next() (segment.Posting, error) {
 		}
 	}
 
-	rv := &Posting{
-		iterator: i,
-		docNum:   uint64(n),
-	}
+	i.next = Posting{} // clear the struct.
+	rv := &i.next
+	rv.iterator = i
+	rv.docNum = uint64(n)
 
 	var err error
 	var normBits uint64