Update to SQLite 3.7.16.2

From the SQLite mailing list:

> The 3.7.16.2 patch release contains a two-character change in the Windows OS interface that fixes a long-standing race condition that could lead to database corruption.   This bug has apparently existed in the code every >since version 3.0.0.  The corruption opportunity arises as follows:
>
> (1) A process crashes or is killed while in the middle of a COMMIT, leaving behind a hot journal that needs to be recovered.
> (2) Two or more new processes attach to the database and try to run the recovery at the same time.
>
> If step (2) happens on a fast multi-core machine, and you are unlucky, then the xCheckReservedLock() method of the OS interface object might return a false positive result, deceiving one of processes into thinking that the recovery had already been accomplished and causing that process to delete the rollback journal and thereby corrupting the database.
>
> [...]
>
> This problem was found internally while conducting stress testing for other components of SQLite.  We have never received a report of database corruption from the wild that can be traced back to this flaw.  Nevertheless, it seems prudent to get a fix into circulation as quickly as possible.