feat: HTTP Client Semconv v1.17 Span Naming

[arielvalentin]

It corrects the span name for the old semantic conventions where the name should be set to the HTTP Method or the literal HTTP as well as adds the url.template to the name when using stable conventions.

HTTP spans MUST follow the overall guidelines for span names.

HTTP span names SHOULD be {method} {target} if there is a (low-cardinality) target available. If there is no (low-cardinality) {target} available, HTTP span names SHOULD be {method}.

(see below for the exact definition of the {method} and {target} placeholders).

The {method} MUST be {http.request.method} if the method represents the original method known to the instrumentation. In other cases (when {http.request.method} is set to _OTHER), {method} MUST be HTTP.

The {target} SHOULD be one of the following:

http.route for HTTP Server spans
url.template for HTTP Client spans if enabled and available (Development)
Other value MAY be provided through custom hooks at span start time or later.
Instrumentation MUST NOT default to using URI path as a {target}.

More explicitly stated, when using old conventions the span name will be one of the known HTTP method (GET, PUT, POST, PATCH, DELETE...) or HTTP if the method is non-standard.

When using dup or stable conventions the name may contain a url.template value if it is known at the time or the request. Users may provide a url.template via the ClientContext attributes.

Some concessions:

1. This change intentionally preserves structural and knowledge duplication in each client gem as a secibd step refactoring to extract and move the functionality into a shared helper gem or the semantic conventions gem.
2. I am deferring supporting OTEL_INSTRUMENTATION_HTTP_KNOWN_METHODS environment variable to a future PR

See #1779

Notice to reviewers

This is a follow up to #1781

[hannahramadan]

@arielvalentin overall looks great! The one thing that caught my eye are the edits for old span names. In a prior PR, I know we fixed old span names that were implemented incorrectly when there was an unknown method: HTTP N/A -> HTTP.

For this PR, we are changing old, but old spec compliant, spans: HTTP GET -> GET.

Should we be updating these names?

[arielvalentin]

@kaylareopelle OK so you are saying we want to stick with the spec v1.17 or earlier for old and then v1.18+ for dup and new?

[hannahramadan]

@arielvalentin yes!

[arielvalentin]

@kaylareopelle Any reason why we would not want to support v1.18+?

[arielvalentin]

@kaylareopelle @hannahramadan I have rolled back the changes to v1.17 span names.

I can keep renaming spans myself in the collector but I would be keen on getting old span names to v1.18 because it would reduce the bytes we transfer from the SDK and reduce the processing and span renaming in our collectors.