BUG: Fix equality behavior for Literal ops

[icexelloss]

The Problem

Currently the equality method for Literal is ill defined, e.g.:

>>> a = Literal(1, datatypes.int16)
>>> b = Literal(1, datatypes.int32)
>>> a != b
False
>>> a == b
True
>>> hash(a)
1536673607048974696
>>> hash(b)
-4587729510117789678

This IMO is bad behavior because it breaks the contract of equal and hashcode (if a == b, then hash(a) must == hash(b)).

What's even worse:

>>> a = ibis.interval(hours=1).op()
>>> b = ibis.interval(seconds=1).op()
>>> a == b
True

Here a and b are totally different objects.

The Fix

The PR proposes a fix where we also checks the dtype equality in literal equality check.

This fix deals with the two problems above. However, it does change some existing behavior:

Before the PR:

a = Literal(1, datatypes.int16)                                                                                                                                                                       
b = Literal(1, datatypes.int32)

a == b # True

After the PR:

a = Literal(1, datatypes.int16)                                                                                                                                                                       
b = Literal(1, datatypes.int32)

a == b # False

I'd like to be more careful with this and hear what other people think. I think after PR behavior is more correct but might break people's code if they are relying the correct behavior. Thoughts?

[icexelloss]

Related to #2386

[jreback]

hmm, this doesn't break anything. interesting. ok let's add a whatsnew note and merge it.

[icexelloss]

Thanks! Updated release notes.

[jreback]

thanks @icexelloss