v0.6.3→v0.7.0 SQLite bump without any other changes

[nyurik]

This PR addresses libsqlite3-sys security issue, by simply updating it in the v0.6.3, and due to the breaking change, bumping the version to v0.7.0, per #1163 (comment)

Note that this SHOULD NOT be merged to main. Maintainers, please create a new branch named v0.6 based on the tag v0.6.3. This way I can retarget this PR to it, it can be merged and deployed, while the main branch will be bumped to 0.8+

[abonander]

#2094 (comment)

[abonander]

We've gotten yelled at before for upgrading libsqlite3-sys because there can be only one version of it in the dependency graph, making it a breaking change for anyone using it directly or rusqlite.

[nyurik]

@abonander please take a look at #1163 (comment) -- that's the whole idea of this PR -- sqlx can release v0.7.0 (a breaking change), while all the current code in the main branch will be treated as v0.8.0+

[nyurik]

P.S. In other words, a release version is cheap -- we do not need to release the current main as v0.7 -- it just as well can be release as v0.8 or even v1.0 -- as long as we indicate that the sqlite bump is not compatible with v0.6.3 (by making it v0.7+), we can move forward

[abonander]

We already have alphas out for the next release and people have started to migrate to them. I plan to set aside some time to prepare the full release in the next week or so.

Unless another one has popped up that I don't know about (this is the one we're talking about, right?), I disagree with the severity of the CVE as it is relatively straightforward to audit your codebase for, would require manual user intervention to fix either way, and passing untrustworthy, unvalidated, unlimited-size strings to a C function via SQL seems like a bad idea to begin with.