[asgi] Allow to attach custom attributes

Is your feature request related to a problem?
The http.server.duration metrics provided by the asgi instrumentation are great to get started with metrics, however they have one shortcoming, which is that they don't have all the information that's required to make decisions.

For example in our multitenant setup, we would like to have the entity id as attribute (cardinality is not too high). We would also like to group several targets under the same api name (not necessarily the same service) and also track the version (v1 vs v2).

Describe the solution you'd like
We would like to be able to attach additional attributes to the final reported metrics. To achieve this we have the idea of attaching a list of string key value pairs to the scope, under a predefined key (like otel_user_attrs). In that way the asgi middleware, and potentially others, could grab the extra attributes before reporting the metric. Just like it's done today with http.target.

The advantage of doing it like this is that any asgi framework (fastapi, starlette, starlite, etc), could modify the scope to attach the info.

The scope field could be defined as:

scope["otel_user_attrs"] = {"api.name": "httpbin", "api.version": "2", "sass.customer": "customer_id"}

and then the code in the middleware grab it as following:

def _collect_user_attributes(
    scope: typing.Dict[str, typing.Any]
) -> dict[str, str]:
    """
    Returns the user defined attributes.

    This value is suitable to use in metrics and traces
    """
    return scope.get("otel_user_attrs", {})
    
...
   user_attrs = _collect_user_attributes(scope)
   duration_attrs |= user_attrs
   self.duration_histogram.record(duration, duration_attrs)

Describe alternatives you've considered
We have considered replacing this library with our own, but we'd prefer if we could contribute back to upstream.

Additional context
I've already sent some improvements to the asgi middleware, and I'm willing to send a PR for this change. @srikanthccv does the proposal make sense to you?

Start with the ASGI middleware and the existing handling of http.server.duration and http.target described in the issue. Trace how the scope reaches metric reporting, then define and consume the proposed otel_user_attrs mapping so custom attributes appear in the final metrics; done means the behavior is covered by the project's existing tests.