Equality subclasses unnecessarily allow null arguments

[natebosch]

When we migrated to null safety we introduced a discrepancy and unnecessarily expanded the argument types for equals and hash.

We declare most of the classes to implements Equality<T>, but allow a T? for equals and hash, so when they are used directly they allow null arguments, but when used as an Equality the functionality is unnecessary.

For _UnorderedEquality this came from making T unnecessarily nullable, and in other subclasses the class level generics are fine but the method arguments are still expanded to allow null.

This entire test should be static errors in my opinion:

collection/test/equality_test.dart

Lines 243 to 267 in cd46e19

	test('Equality accepts null', () {
	var ie = IterableEquality();
	var le = ListEquality();
	var se = SetEquality();
	var me = MapEquality();
	expect(ie.equals(null, null), true);
	expect(ie.equals([], null), false);
	expect(ie.equals(null, []), false);
	expect(ie.hash(null), null.hashCode);
	expect(le.equals(null, null), true);
	expect(le.equals([], null), false);
	expect(le.equals(null, []), false);
	expect(le.hash(null), null.hashCode);
	expect(se.equals(null, null), true);
	expect(se.equals({}, null), false);
	expect(se.equals(null, {}), false);
	expect(se.hash(null), null.hashCode);
	expect(me.equals(null, null), true);
	expect(me.equals({}, null), false);
	expect(me.equals(null, {}), false);
	expect(me.hash(null), null.hashCode);
	});

Changing the arguments to non-nullable (with some extra handling of the nulls that flow from libraries that have not migrated to null safety) is a better design, but the impact of the breaking change is likely higher.

Changing the implements to implements Equality<T?> gives a more accurate interface and expands the places these classes can be used, but is still breaking.

See #161 (comment)

[natebosch]

We could also keep the nullable arguments but leave the implemented interface as non-nullable and exclusively fix the generics of _UnorderedEquality to fix the issue discussed in #161

This is the least likely to break anything and does make some potential usage a bit better I think. I'll check how much it breaks internally to get an idea of the feasibility.

[natebosch]

Keeping this open to consider whether we should remove the nullable argument types.