Feature - Prepping 3.1.0 Release

[cnoon]

This PR updates SQift to Xcode 9.3 and and fixes any compiler warnings from Swift 4.1. The change worth calling out here is the removal of the CodableBinding protocol extension explicitly setting the BindingType associated type to Data in a typealias. The Swift 4.1 compiler now complains that you shouldn't do that and should instead define the protocol extension with a generic constraint. See this Swift forum thread and SR-7324 for more info.

I'm a bit torn as to how we should release this change. The options I see are:

1. Release this as a PATCH release and ignore the fact that the Swift 4.1 change requires us to make a non-backwards compatible change to get rid of a warning
2. Release this as a MAJOR version release since we're required to make a non-backwards compatible change to silence the compiler warnings
3. Release a PATCH release and leave the compiler warning in there. Then fix the compiler warning when we actually start working on SQift 4.x.

   It is important to note that SQift 4.x is not currently on our radar in any capacity.

Let's openly discuss these options in this PR to iron out the best way to release Swift 4.1 and Xcode 9.3 support.

[cnoon]

This is the change worth calling out. The Swift 4.1 compiler throws a warning now when defining the typealias in the protocol or the protocol extension. And rightfully so, because it can lead to all sorts of odd behavior when redefining the typealias in conforming types or subclasses.

[AtomicCat]

Read the thread and SR and the change seems like the right thing to do, but to make sure I'm grokking this... with the new syntax, this extension is only available when the BindingType type is Data, correct?

How does this break existing users of the code?

[cnoon]

Great question. The only place this would break an existing user is if you had created a CodableBinding type such as a Person struct that you wanted to write directly into the database as a data blob. We actually have these in the test suite.

[AtomicCat]

Ah, makes sense. I'd suggest #1 as the version strategy. While this does require changes to the callers code, it's more of a slight language shift caused by Swift 4.1 than a "we actually changed the API" thing. This doesn't feel like a major version change to me.

[cnoon]

Here's an example @AtomicCat of the change clients would be required to make on Swift 4.1.