Use a failable iterator when selecting records

[calvincestari]

The prepare function being used in selectRawRows(forKeys:) is changing behaviour such that errors during iteration would be hidden. We can keep the expected error-on-iteration behaviour by switching to a row iterator that supports failure. This PR changes the internals of selectRawRows(forKeys:) to use prepareRowIterator, returning a RowIterator which conforms to FailableIterator therefore any error thrown would still be propagated out to the caller.

This PR does not move the dependency version of SQLite.swift to 0.13.0

• It requires apollo-ios to move to a minimum deployment target of 10.15 for macOS
• There are multiple deprecations in the change to target 10.15 that should be addressed separately
• Once the deprecations are handled moving to SQLite.swift 0.13.0 will be seamless

[calvincestari]

I don't think there is any test required for this change. I initially wanted to ensure that RowIterator.map uses failableNext internally which throws errors but that's both the wrong thing to test and this is the wrong place for that test.

I added testSelection_withForcedError_shouldThrow.

[calvincestari]

@AnthonyMDev is this what you had in mind for a test? Directly calling selectRawRows(forKeys:) is as close to the change as we can get. The table we use is extremely basic so I don't think it's possible to force an error through data without doing something more drastic. So I chose to drop the table instead of the nuclear option like deleting the database.

[AnthonyMDev]

I think so! Let's just verify by making sure this test fails once we update to SQLite 13.0.

[calvincestari]

We'd have to cherry-pick the test into a branch that doesn't contain the change to use prepareRowIterator - but yes, good validation once we move.

[calvincestari]

To prove that this change works I created a branch that:

1. Bumped the SQLite.swift dependency version to 0.13.0 which contains the iterator behaviour change (from this)
2. cherry-picked the test from this PR
3. Pushed to GitHub to trigger a CI build

The CI build failed as expected which proves the hypothesis that if this change were to go out in a 0.12.3 release then developers using apollo-ios would get silently changed behaviour.

I'm not sure how long CI builds are kept for so for prosperity the screenshot below is from the failed CI build

And all four of those failed steps are failing with the same error

[AnthonyMDev]

Thanks for this Calvin!