API overhaul

[jberkel]

Especially w.r.t error handling

• NSDate fetch crash on some dates #302
• Error handling #413
• Don't crash in Statement.next. #569

[MrMage]

Not sure if this is related, but I recently changed Statement.next() to avoid using try!, as this occasionally caused crashes in my app. (Only when the SQLite DB was malformed, but still.) Instead, Statement.next now returns either a "success" result or the error thrown by .step().

In case you are interested, the commit at hand is Timing-GmbH@c2f9cd0. I'm not suggesting cherry-picking this 1-by-1, but if you are about to overhaul the API anyway, consider changing Statement.next() to return a "success-or-error" type instead of using try!. Adding throws to the method signature would be the nicer approach, but unfortunately that would break Statements conformance to IteratorProtocol.

[jberkel]

@MrMage thanks! this has already been discussed in #569. A Either type solution was proposed there as well. Right now there's a "stop-gap" solution in 0.11.4 with #726 but I'm not completely happy with that. The FailableIterator type introduced there doesn't really work well with the remaining Swift types. For 0.12 we could rethink some of these approaches.

[MrMage]

Thanks for the elaboration! Looking forward to whatever improvements you come up with :-) I think the `Cursor` approach is not bad, but I would also suggest making that return `RowResult`s instead of optional `Row`s.