[BEAM-3306] Hash keys when lifting

[lostluck]

Hash key values when combiner lifting using the registered coder for the type.
Specialized for numeric primitive types to avoid unnecessary work.
This turns out to be faster than the general "interface{}" hashing we had previously for numeric type, and is comparable, but marginally slower than native maps with the primitive numeric type as keys.

Strings are currently much slower as keys than the native go runtime approach for interfaces{}, as the runtime uses a better hash function.
General struct performance (for values Go supported as keys) will be much slower than the go runtime.
Pointer elements (with coders) used as keys will be slower, but they'll also be correct, which wasn't the case previously.
Care needs to be taken using Maps in Key values, as the Go SDK does not presently sort maps in any fashion prior to encoding. Combined with go map's random iteration order, means combines with such keys will not be valid.

A separate in PR will add vetting for this case, to discourage the use of map fields in key types.

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Choose reviewer(s) and mention them in a comment (R: @username).
• Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

Post-Commit Tests Status (on master branch)

Lang	SDK	Apex	Dataflow	Flink	Gearpump	Samza	Spark
Go		---	---	---	---	---	---
Java
Python		---			---	---	---

[lostluck]

R: @aaltay Review please! Thanks.