`opentelemetry-instrumentation-pymssql`: expose `capture_parameters`

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

Background

pymssql builds on the dbapi base but defines its own
DatabaseApiIntegration subclass. Once the dbapi sub-issue lands the base knows
how to emit 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 the dbapi wrapping call.
• In instrument_connection, add a capture_parameters parameter and pass it
  through.
• Ensure the pymssql DatabaseApiIntegration subclass forwards
  capture_parameters to the base (check its __init__ / factory usage so the
  flag is not dropped).
• 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 through the pymssql subclass to the
  dbapi layer for both entry points.
• Verify db.query.parameter.<key> appears under the new semconv when enabled.

Locate the pymssql instrumentor, its _instrument and instrument_connection entry points, and the DatabaseApiIntegration subclass or factory usage. Compare the psycopg2 instrumentation for capture_parameters, then add forwarding tests for both entry points and verify the new and old semantic-convention attributes while keeping the default disabled.