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

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

Background

tortoiseorm 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.

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.
• Key positional parameters by 0-based index and named parameters by name,
  depending on what the underlying driver passes through Tortoise.
• Do not capture parameters on batch operations (executemany).
• If the package does not yet resolve the database semconv opt-in mode, wire it
  up the same way the other database instrumentations do.

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 operations 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.

Start by locating the TortoiseORM instrumentation and its tests, then read the shared _set_db_query_parameters helper in opentelemetry.instrumentation._semconv and the other database instrumentations' semconv opt-in handling. Add coverage for old, new, and database/dup modes plus executemany, verifying exact parameter attribute names, string values, and the required absence or presence of legacy attributes.