ToricVarieties: Add Base.hash

[HereAround]

Should we add Base.hash for our custom types (AffineNormalToricVarieties, AbstractNormalToricVarieties, ToricDivisors, ToricDivsiorClasses, ToricLineBundles, (soon ToricVectorBundles and ToricCoherentSheaves) and many more...)?

C.f.: https://docs.julialang.org/en/v1/base/base/#Base.hash

[thofma]

Here is my opinion.

1. Element types should definitely define a two argument Base.hash method so that x == y implies hash(x, h) == hash(x, y). This leads to less surprises down the road with Dict, Set or unique. It gets more complicated if there is no canonical way to represent elements, but where one can still decide x == y. Then it is best to define hash(x, h) == zero(UInt) for this type.
2. For parent types it is a bit more complicated, since the meaning of == is not too clear. For almost all the parent types coming from AbstractAlgebra/Nemo/Hecke/Singular, we consider parent objects equal if they are identical (so R == S always falls back to R === S, which is equivalent to objectid(R) == objectid(S), i.e., the "addresses" in memory are equal.). As the default hash for mutable types falls back to comparing objectid's, this is fine. So for example,

   julia> R = abelian_group([2])
   GrpAb: Z/2
   
   julia> S = abelian_group([2])
   GrpAb: Z/2
   
   julia> R == S
   false
   
   julia> R === S
   false
   
   julia> hash(R)
   0x9ae54f16dff512cb
   
   julia> hash(S)
   0xdfa4d36923bf8c61

Someone (@fingolfin, @ThomasBreuer) can probably say something more about groups.

[fingolfin]

We are currently more generous for == when it comes to permutation groups, mostly because we are following GAP semantics. For fp groups it's basically the same as for the ablian groups above.

I do see a method

function Base.:(==)(td1::ToricDivisor, td2::ToricDivisor)
    return toric_variety(td1) === toric_variety(td2) && coefficients(td1) == coefficients(td2)
end

so that means there definitely should be a Bash.hash method for ToricDivisor