Fix cardinality of opentelemetry span names on client-side navigation

[PatNeedham]

Duplicate of vercel#59282 in order to (hopefully) regenerate the GH Action logs from the failing tests.

For Contributors

Fixing a bug

• Fixes High-cardinality HTTP span names vercel/next.js#54694 (at least partially)
• Adds test case for client-side navigation previously leading to wrong span attributes (test added into the test/e2e/opentelemetry test suite)
• Updated test/e2e/opentelemetry app used to test telemetry (some pages with link between them where created but not quite correct in the links, and were not handling the defined params)

Adding a feature

• Implements an existing feature request or RFC. Make sure the feature request has been accepted for implementation before opening a PR. (A discussion must be opened, see https://github.com/vercel/next.js/discussions/new?category=ideas)
• Related issues/discussions are linked using fixes #number
• e2e tests added (https://github.com/vercel/next.js/blob/canary/contributing/core/testing.md#writing-tests-for-nextjs)
• Documentation added
• Telemetry added. In case of a feature if it's used or not.
• Errors have a helpful link attached, see https://github.com/vercel/next.js/blob/canary/contributing.md

What?

As noticed in issue vercel#54694, span names for dynamic routes are not consistent and sometimes miss the "next.route" attribute, and have a span name that have the parameters instead of the capturing placeholders.