feat: HTTP Client Semconv 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

The relevant commit in this PR is
49c6dc0