feat: add a __hash__ implementation to AccessEntry

[spennymac]

added __hash__ to AccessEntry

Closes #94.

[spennymac]

#94

[plamut]

The __hash__() implementation looks good, let's just add a few tests covering it, e.g. making sure they can be added to (and located in) sets and dicts, equal instances having the same hash, etc.

The only potential concern is that the change makes the AccessEntry instances immutable (required with this hash implementation). I wonder if there is any user code that actually mutates these instances, as this change will break it? (cc: @shollyman)

Nevertheless, it's a simple class similar to DatasetReference, which is already hashable (and immutable), and its main purpose is just to group a few values, thus making AccessEntry immutable for hashability seems reasonable IMO.

[spennymac]

added two tests

[plamut]

LGTM.

Will wait with merging, though, until the product gives a green light, as this is a potentially breaking change for some users.

[shollyman]

The pattern I can think of where mutable ACE mutations be leveraged is for code that amends an ACL via dataset update. There are cases where walking the existing ACL to amend the entries might be happening via direct mutation rather than replacing via a newly constructed ACE.

I tried to search for code examples that mutate ACEs in place, but I didn't find anything with a coarse pass. The much more common idiom is appending an entry to an existing ACL. I can't think of any existing integrations that would do this, it feels like a very specific action.

This feels relatively low risk, and not sufficient to necessitate a major rev in release to me. Peter, let's make sure we call this out clearly in the release notes however.