`opentelemetry-instrumentation-sqlite3`: expose `capture_parameters`

Part of #4787 (global db.query.parameter.<key> tracking issue).

Background

sqlite3 builds on the dbapi base, so once the dbapi sub-issue lands it
already emits db.query.parameter.<key> correctly — but only when
capture_parameters=True. The instrumentor never exposes that option, so users
have no way to enable parameter capture.

psycopg2 already exposes capture_parameters and is the reference
implementation.

What to do

Thread a capture_parameters option through the instrumentor, mirroring
psycopg2:

• In _instrument, read capture_parameters = kwargs.get("capture_parameters", False)
  and pass it to dbapi.wrap_connect(...).
• In instrument_connection, add a capture_parameters parameter and pass it
  to dbapi.instrument_connection(...).
• Document the option in the module docstring.

No parameter-formatting logic lives here — it all comes from the dbapi base.

Acceptance criteria

• instrument(capture_parameters=True) and
  instrument_connection(conn, capture_parameters=True) both enable capture.
• With capture enabled, spans carry db.query.parameter.<key> under the new
  semconv and db.statement.parameters under the old semconv (via the base).
• Default remains no parameter capture.

Tests

• Verify capture_parameters is forwarded to the dbapi layer for both entry
  points.
• Verify db.query.parameter.<key> appears under the new semconv when enabled,
  including named parameters (sqlite3 supports :name and ? styles).

Start with the sqlite3 instrumentor entry points _instrument and instrument_connection, then compare the psycopg2 implementation and the dbapi.wrap_connect and dbapi.instrument_connection calls. Run the sqlite3 instrumentation tests to verify forwarding through both entry points, parameter attributes under both semconv versions, named parameters, and the default-disabled behavior.