🐛 fix(sqlite): isolate forked connections

[gaborbernat]

SQLite forbids a process from using or closing a database connection inherited through fork(). Read-write locks kept
one connection for the object's lifetime, so a child could close its parent's handle during interpreter shutdown and
corrupt the database. Each outer acquisition now owns its connection, and a forked child abandons inherited handles
according to
SQLite's fork guidance.
Closes #635.

The child rejects an active database by canonical path or inode until exec(). CPython 3.10 and 3.11 keep inherited
base connections alive through a raw-reference escrow; later CPython versions use the guarded subclass finalizer. The
implementation follows the
CPython 3.10 _sqlite lifecycle and
current CPython source. A child forked from
a SQLite callback waits for the call to leave SQLite, or exits with status 70 if an earlier audit hook prevents
coordination. Fork registration uses a reentrant gate because connection finalizers can register another lock while the
current thread owns that gate.

PyPy can retain unsafe process-wide SQLite state after tracked connections close. A PyPy child rejects read-write locks
when the parent used SQLite after importing filelock; importing filelock in the child cannot detect earlier parent use.
The public acquisition interfaces stay unchanged. Final release closes the per-acquisition connection. A local
2,000-acquisition benchmark measured 5.7 microseconds for the former persistent connection and 45.6 microseconds for the
per-acquisition design.