Make Edit a type of a Collection

[osteslag]

This set of changes is about making Edit a type of a collection instead of a collection’s equatable elements plus the resulting changed requirements, including tests and test app. Merges into the version 3 branch.

An Edit needs to have a concept of the collection type so we can ensure we can do arithmetic on the collection’s index distance type, see discussion on #39.

I wasn’t able to declare …where C.IndexDistance: SignedInteger on Edit, Changeset while doing enumerations and additions/subtractions on offsets in a compatible way. At least I couldn’t figure out how to. So for now, we require Int index distances on the collections.

Note: I prefer to ensure all commits are compilable (git-bisect), hence all files in one commit.

FYI: I’m planning a general cleanup for version 3 (including using the C shorthand for Collection types, probably splitting up Edit and Changeset in separate files).

[ole]

That was fast! I'll take a look at it soon.

[osteslag]

I have a full-time job, so I could have been much faster 😉
But compared to the previous PR, based on your comment in April, I guess you’re right 😆

[ole]

@osteslag I haven't reviewed the changes yet, but I spent some time on getting rid of the IndexDistance == Int constraint. See #41.

[ole]

I pushed one commit removing some redundant constraint. Xcode 9 detected them for me. Xcode 8 doesn't show the warnings, but they are still redundant; the project compiles and runs without them just fine.

Everything else looks good to me. 👍

[osteslag]

Good change! Clearly Collection as well as the other Edit collection constraints are inferred via Edit<T>.