`opentelemetry-instrumentation-asyncpg`: capture `db.query.parameter.<key>`

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

Background

asyncpg does not build on the dbapi base. It independently captures
parameters as the non-standard db.statement.parameters blob (a single
stringified value) when capture_parameters=True. It already uses the semconv
stability opt-in mechanism (_StabilityMode / _report_new).

What to do

• Reuse the shared _set_db_query_parameters helper from
  opentelemetry.instrumentation._semconv (added in the dbapi sub-issue).
• When capture_parameters is enabled:
  • emit db.statement.parameters only under the old semconv;
  • emit db.query.parameter.<key> under the new semconv via the helper.
• asyncpg passes positional query arguments; key them by 0-based index.
• Do not capture parameters for the batch execution paths (e.g. executemany).

Acceptance criteria

• Old semconv: db.statement.parameters unchanged; no db.query.parameter.*.
• New semconv: db.query.parameter.<key> emitted; no db.statement.parameters.
• database/dup: both present.
• Values captured as strings; batch executions do not emit
  db.query.parameter.*.

Tests

• Cover old / new / dup modes and the batch case.
• Verify exact attribute names and string value types against the spec.
• Exercise the async execute paths.

Start with the asyncpg instrumentation's asynchronous execute paths and the shared _set_db_query_parameters helper in opentelemetry.instrumentation._semconv. Run or extend the instrumentation tests for old, new, and dup stability modes plus batch execution; done means exact attribute names, string values, and no parameter attributes on batch paths.