BUG: Register SQLite adapters only once per process (GH#64337)

[q121212]

Every call to DataFrame.to_sql() with a SQLite connection creates a new SQLiteTable
instance, whose __init__ unconditionally calls sqlite3.register_adapter() and
sqlite3.register_converter() — global mutations. After Python 3.12 removed the
default adapters for datetime types, pandas added its own (commit c9a8f95f).
But re-registering them on every to_sql() call overwrites any custom adapters or
converters the user may have registered.

Side-effect analysis

Without pandas' adapters, to_sql() crashes on Python 3.12+ when inserting
datetime.time, datetime.date, or datetime.datetime columns. The built-in
sqlite3 module no longer provides default adapters for these types.
Therefore, we cannot simply stop registering — we must keep the registration
but make it non-destructive.

Fix

Use a module-level _SQLITE_ADAPTERS_REGISTERED flag to ensure adapters and
converters are registered only once per process lifetime. After the first
to_sql() call, subsequent calls are no-ops and no longer overwrite user
handlers.

File: pandas/io/sql.py

# Module-level state
_SQLITE_ADAPTERS_REGISTERED: bool = False

class SQLiteTable(SQLTable):
    def _register_date_adapters(self) -> None:
        import sqlite3

        global _SQLITE_ADAPTERS_REGISTERED
        if _SQLITE_ADAPTERS_REGISTERED:
            return

        # ... register adapters and converters as before ...

        _SQLITE_ADAPTERS_REGISTERED = True

Added test

File: pandas/tests/io/test_sql.py

test_to_sql_preserves_user_sqlite_adapters — verifies that a custom
adapter registered after the first to_sql() call is NOT overwritten
by subsequent to_sql() calls.

Limitations (documented)

If the user registers custom adapters before their first to_sql() call,
pandas will still overwrite them on that first call. This is the same as
current behavior. A follow-up PR can implement save/restore for full
protection.

Checklist

• Bug fix
• Tests pass: pytest pandas/tests/io/test_sql.py -k test_to_sql_preserves
• No new dependencies
• Backward compatible — all existing to_sql behavior preserved
• No performance regression (single boolean check)