[murmur] Fix MurmurBytes
[murmur] Fix MurmurBytes

The current MurmurBytes has a wrong implementation because given the same parameter it could return 2 different values.
Consider this simple program:
```go
package main

import (
    "fmt"
    "github.com/DataDog/hyperloglog"
)

func main() {
    var s1 string = "hello"
    fmt.Println(hyperloglog.MurmurString(s1))
    fmt.Println(hyperloglog.MurmurString(s1))
}
```

The output is different.
This is because currently we unsafe convert a string to a slice.
Unfortunatly the SliceHeader & StringHeader are different: https://golang.org/pkg/reflect/#SliceHeader

```go
type SliceHeader struct {
        Data uintptr
        Len  int
        Cap  int
}
type StringHeader struct {
        Data uintptr
        Len  int
}
```

So when converting `StringHeader` to `SliceHeader` `Data` & `Len` are the same place but `Cap` will
be completly garbage (whatever byte is after)

What happened is when `Data="hello", Len=5, Cap=0`, doing a slice `data[4:]` will actually return `h` and not `o`.
This is probably because Cap < Len (which should never happen).
Unfortunatly we cannot edit the `SliceHeader.Cap` without creating at least another Header object otherwise we
would edit memory data of another thing.
So we need at the minimum to create a `SliceHeader`, that's what we do here.

Since potentially (UTF-8), I would say len(string) != len(bytes), I would actually be partial to just eat it up
and do the copy like before.

Here are the benchmarks:

Current (incorrect) behavior vs creating a `SliceHeader`:
```
name               old time/op  new time/op  delta
100MurmerString-4  1.04µs ± 3%  1.37µs ± 3%  +31.44%  (p=0.000 n=10+9)
```

So it's ~30% slower

Current behavior vs copy:
```
name               old time/op  new time/op  delta
100MurmerString-4  1.04µs ± 3%  1.84µs ± 2%  +76.47%  (p=0.000 n=10+10)
```

So almost 2x slower

We need the `SlicerHeader` anyway so doing a copy instead is:
```
name               old time/op  new time/op  delta
100MurmerString-4  1.37µs ± 3%  1.84µs ± 2%  +34.25%  (p=0.000 n=9+10)
```

~35% slower so I'd still be of the opinion to just eat it up and do the copy

DataDog/hyperloglog