Implement new stable URL semantic conventions

[mateuszrzeszutek]

... and use them as part of the HTTP extractors - the HTTP getters now extend the UrlAttributesGetter, and override the methods that HTTP semconv is interested in.

This PR also sets up the OTEL_SEMCONV_STABILITY_OPT_IN env var handling, and adds some tests that cover all 3 possible variants of emitted attribute sets.

[trask]

I think I slightly prefer consistency with other *Getter classes of not repeating Url in the method names, e.g.

• getFull()
• getScheme()
• etc

[mateuszrzeszutek]

That was my initial idea to.

But, the problem with the HTTP semconv is, it uses other semconv (URL, client, server, network) and slightly overrides how some of the "inherited" attributes are extracted. For example, client.address will be extracted from the Forwarded header if not provided; or server.port will be taken from the Host header, but only if it's not 80/443.

To apply these customizations we either have to pass multiple getters to the extractor (which is what we're doing right now; in the new semconv it would be 5 getters instead of 2 though), or have the HTTP getter extend the "inherited" semconv getters - in which case, something likegetFull() appearing on an HTTP getter would be mildly confusing to the user. Which is why I've chosen to be a bit more verbose here.

[brunobat]

Should we also have a target? a low cardinality attribute for things like:
`/search/{something}

[mateuszrzeszutek]

For HTTP semconv, http.route contains that kind of information.

In general, these classes are meant to reflect the semantic conventions -- if you want to introduce a new attribute, you might want to start there.

[mateuszrzeszutek]

Some notes from the meeting:

• The server.*, client.* and network.* namespaces will get their respective getters (and extractors); the HTTP getters will extend them;
• Other instrumentations (e.g. RPC, or the upcoming Elasticsearch instrumentation) could simply use the UrlAttributesExtractor/NetworkAttributesExtractor/etc;
• We could remove the getFullUrl() method from UrlAttributesGetter and move it entirely to the HttpClientAttributesGetter; this would remove some confusion about attributes that are not really supposed to be emitted by the HTTP client instrumentations but still available in the getter;
• The UrlAttributesGetter would be left with just the URL components, without the full URL;
• Every getter method would include the full name of the attribute, e.g. getUrlFull, getHttpRequestMethod etc.

[trask]

I think this would better handle http://xyz/path? (also related open-telemetry/opentelemetry-java#5501)

Suggested change

	return (path == null ? "" : path) + (query == null || query.isEmpty() ? "" : "?" + query);
	return (path == null ? "" : path) + (query == null || "?" + query);

[mateuszrzeszutek]

I found that some HTTP servers always return a non-null value for query, even if the called URL does not contain the query component.
I'll revert to the old behavior and merge this PR; let's discuss if we want to change this behavior in the old semconv separately (I made the new url.* extractors always add a non-null value for query)