Add tests for equals() and forEach() on keySet() and entrySet().

[motlin]

No description provided.

[mohrezaei]

With the recent changes to make Entry objects mutable, should we add tests that make sure immutable maps and synchronized maps act correctly if someone tries to mutate with forEach?

[motlin]

With the recent changes to make Entry objects mutable, should we add tests that make sure immutable maps and synchronized maps act correctly if someone tries to mutate with forEach?

For sure! For context, I started working on #500 about 3 months ago, and I have lots of changes staged on a few branches, including lots of additional test coverage.

• master...motlin:eclipse-collections:unmodifiable-map
• master...motlin:eclipse-collections:unmodifiable-map-2

When I put stuff like this up for review, the reviews are too big to get anyone to read through. I'm finding them difficult to split up and land separately as well. Lots of the assertions that I pull up to superclasses expose real differences between the maps. None of them are earth shattering, but they slow me down.

• Whether Entries support mutation, which in turn affects whether default methods like Map.replace() throw
• Which exception is thrown when null is passed in
• Whether a method that may perform mutation like getIfAbsentPut always throws or only throws on mutation
• Other stuff that I'm forgetting now.

I'm confident that immutable maps will never mutate through Entries, but it's possible they throw different exceptions from different maps.

While I haven't pulled up tests of setValue() into the interface-based tests yet, there is already some coverage in the old-style tests.

eclipse-collections/unit-tests/src/test/java/org/eclipse/collections/impl/map/mutable/UnmodifiableMutableMapTest.java

Line 439 in 9012729

assertThrows(UnsupportedOperationException.class, () -> Iterate.getFirst(map.entrySet()).setValue("Three"));

[motlin]

This one has been open for a while and just adds test coverage. Any objections to landing it?