go: Eliminate memory allocations and reduce Decode time by 26%

[willbeason]

Use handwritten version of strings.Map logic. This avoids having to dynamically allocate and resize the byte slice, and allows the compiler to fully remove memory allocations from the operation. As a result, the time spent in StripCode is almost completely removed.

Before:

$ go test . -bench=Decode -benchtime=10s
...
goos: linux
goarch: amd64
pkg: github.com/google/open-location-code/go
cpu: AMD Ryzen Threadripper 3970X 32-Core Processor 
BenchmarkDecode-64    	32295574	       337.7 ns/op	      24 B/op	       1 allocs/op

After:

$ go test . -bench=Decode -benchtime=10s
...
goos: linux
goarch: amd64
pkg: github.com/google/open-location-code/go
cpu: AMD Ryzen Threadripper 3970X 32-Core Processor 
BenchmarkDecode-64    	48074581	       248.5 ns/op	       0 B/op	       0 allocs/op

CPU Profiles:

Before:

After:

[willbeason]

After this PR, I have another that reduces Decode time further, to ~161.4ns/op. It's a separate optimization so I've split it out.

willbeason@12e4efd

[willbeason]

I see actually that StripCode() is part of the public API, so it's probably better that I don't change it and possibly break someone. I've removed that part of the change. It's still a significant speedup. Future performance improvements don't rely on it (yet), so I'm not worried about touching that now.

$ go test . -bench=Decode --benchtime=10s
goos: linux
goarch: amd64
pkg: github.com/google/open-location-code/go
cpu: AMD Ryzen Threadripper 3970X 32-Core Processor 
BenchmarkDecode-64    	38923173	       270.3 ns/op	      16 B/op	       1 allocs/op

[willbeason]

On that note, I have a third optimization that gets us to ~75ns/op for Decode.

willbeason@54bdf28