feat: improve pipeline tracing for rueidis and valkey with deduplicated resource names

[snutiise]

What does this PR do?

Improve pipeline tracing for contrib/redis/rueidis and contrib/valkey-io/valkey-go by replacing the truncated command concatenation approach with deduplicated, alphabetically sorted resource names and structured pipeline tags.

Before (6 commands: SET x3, GET x3)

• Resource name: "SET GET SET GET SET" (truncated to 5, lossy)
• No pipeline metadata tags

After

• Resource name: "GET SET" (deduplicated, sorted alphabetically, stable grouping)
• redis.pipeline.length: 6 (total command count)
• redis.pipeline.command_counts: "GET:3 SET:3" (per-type breakdown)

Changes applied consistently to both packages

• Replace processCommandMulti / processCommandMultiCache / multiCommand with buildPipelineInfo / countCommandNames / countCacheableCommandNames
• Add ext.RedisPipelineLength, ext.RedisPipelineCommandCounts, ext.ValkeyPipelineLength, ext.ValkeyPipelineCommandCounts constants
• Prevent empty raw_command tag on pipeline spans (rawCommand && cmd.raw != "")
• Update tests with new pipeline tag assertions and add DoMultiCache test coverage

Motivation

The previous implementation concatenated all command names into the resource name (e.g. "SET GET SET GET SET"), truncated to the first 5. This caused

• High cardinality: Different command orderings produced different resource names for the same command set
• Information loss: Commands beyond position 5 were silently dropped
• No quantitative data: No way to know how many commands were in the pipeline

The new approach provides stable resource grouping (same command types always produce the same resource name regardless of count or order) while moving detailed metrics to tags where they belong.

Note: This changes the resource name format for DoMulti/DoMultiCache/DoMultiStream spans (e.g. "SET GET SET GET SET" → "GET SET"). Existing monitors or dashboards filtering on the old resource name format may need to be updated.

Reviewer's Checklist

• Changed code has unit tests for its functionality at or near 100% coverage.
• System-Tests covering this feature have been added and enabled with the va.b.c-dev version tag.
• There is a benchmark for any new code, or changes to existing code.
• If this interacts with the agent in a new way, a system test has been added.
• New code is free of linting errors. You can check this by running make lint locally.
• New code doesn't break existing tests. You can check this by running make test locally.
• Add an appropriate team label so this PR gets put in the right place for the release notes.
• All generated files are up to date. You can check this by running make generate locally.
• Non-trivial go.mod changes, e.g. adding new modules, are reviewed by @DataDog/dd-trace-go-guild. Make sure all nested modules are up to date by running make fix-modules locally.

Unsure? Have a question? Request a review!