Fix hashing for choicemaps

[georgematheos]

This adds a method Base.hash(::ChoiceMap) to Gen, so that (e.g.) choicemaps can be used as keys in dictionaries.

Before this change, the following behavior would occur:

julia> d = Dict(); d[choicemap((:x, 1))] = 2;
julia> haskey(d, choicemap((:x, 1)))
false

Per the Julia documentation, since Gen implements a custom method Base.:(==)(::ChoiceMap, ::ChoiceMap), it should also implement a custom hashing method with the property that a::ChoiceMap == b::ChoiceMap implies that hash(a, h) == hash(b, h) for any partial hash h::UInt.

[ztangent]

Thanks for catching this and making this PR! One worry I have is that because get_values_shallow and get_submaps_shallow do not guarantee a fixed ordering of keys, the resulting hashes may differ depending on iteration order. Could you try adding a test case that compares the hashes of choicemap((:a, 1), (:b, 2)) with choicemap((:b, 2), (:a, 1))? And also sort the values before iterating? Thanks!

[ztangent]

After looking at the Julia implementation of hashing for dictionariesit looks like the easiest way to address the lack of guaranteed order is to repeatedly xor the hashes for each value/submap. Note that you should implement it in a similar way to the fixed implementation to prevent many hash collisions! (See the discussion at https://discourse.julialang.org/t/different-dicts-hashing-to-the-same-value/1441/5)

https://github.com/JuliaLang/julia/blob/7bff5cdd0fab8d625e48b3a9bb4e94286f2ba18c/base/abstractdict.jl#L530-L537

[georgematheos]

Good point -- the hash method should not depend on the order.

@ztangent can you please clarify what you mean by "the fixed implementation"?

[georgematheos]

Oh, never mind -- I think I see what you mean by that. Got it; I will push a fix along these lines in a minute.

[ztangent]

Awesome, looks good to me, thanks for fixing this!