Widen the libsqlite3-sys bound to any 0.x

[MichaelKreil]

Fixes #235.

libsqlite3-sys declares links = "sqlite3", so cargo permits exactly one copy in a graph. The
current ceiling of <0.36 predates 0.36, 0.37 and 0.38, which means proj-sys cannot coexist with
any rusqlite newer than 0.37 - and there is no consumer-side fix, because the dependency is not
optional on either side.

#235 reports this and stalled on the reporter's mention of nix. That was a red herring: this is pure
cargo resolution and happens with no nix involved. Our case is an application using r2d2_sqlite:

Chain	Requires libsqlite3-sys
gdal-sys (bundled) → gdal-src 0.3 → proj-sys 0.27	>=0.28, <0.36
r2d2_sqlite 0.35 → rusqlite 0.40	^0.38

error: failed to select a version for `libsqlite3-sys`.
    ... required by package `proj-sys v0.27.0`
package `libsqlite3-sys` links to the native library `sqlite3`, but it conflicts with a
previous package which links to `sqlite3` as well: package `libsqlite3-sys v0.38.0`

Why widening rather than removing. #190 added this dependency deliberately, to give downstream
control over how libsqlite3 is linked in bundled builds - and it was merged specifically to unblock
georust/gdal's bundled build. That is exactly the case we are trying to use, so removing the
dependency would break the thing it was added for. Only the ceiling looks accidental.

Why the version does not matter. proj-sys's entire coupling to the crate is:

• extern crate libsqlite3_sys; under the bundled_build cfg - linkage only, no API surface
• DEP_SQLITE3_INCLUDE and DEP_SQLITE3_LIB_DIR in build.rs

Both cargo:include and cargo:lib_dir are emitted unchanged by libsqlite3-sys 0.35, 0.36, 0.37
and 0.38, so nothing in proj-sys has to change.

Why <1.0 rather than <0.39. For a links crate a version bound is not only "what I can build
against" - it constrains the whole downstream graph, with no opt-out. So a tight ceiling needs a new
proj-sys release every time libsqlite3-sys ships a minor, and every time it falls behind,
consumers cannot resolve at all. That treadmill is how <0.36 came to be three releases stale.
<1.0 still guards against a genuine 1.0 rewrite, since cargo treats each 0.x minor as breaking
anyway. It does bet that the two build-script keys stay stable across 0.x; if that ever broke, it
would be a clear build error in proj-sys rather than an unresolvable graph for everyone else.

Tested against the case the dependency exists for - a statically bundled GDAL, on macOS/arm64:
it resolves with libsqlite3-sys 0.38.2 alongside rusqlite 0.40, builds GDAL, PROJ and SQLite from
source, links with no gdal/proj/sqlite dylib, and reads a GeoTIFF into tiles with a correct Web
Mercator bbox - so PROJ's embedded proj.db resolves at runtime too.