Add support for passing traceID/spanID in generated metrics

[gagbo]

Description

This PR has a big refactoring to make code generation easier to understand, and also adds the ability for autometrics to track in a context the traceID and the spanID for the currently instrumented function. This is built over a more generic mechanism to attach data to metrics using contexts.

Autometrics also uses its parser to detect common libraries/function signatures, in order to access the context from instrumented code directly: this is necessary to have autometrics pick up the traceID/spanID if it was injected by other means (like a middleware for the web framework being used).

Related to #44 as it is a first necessary step

Checklist

• [ ] The CHANGELOG is updated.
• [ ] The open-telemetry example in repository works fine:
  • the docker compose file is valid
  • the application compiles and run
  • alerts are getting triggered in Prometheus

[gagbo]

There are still blockers for the merge (marked with TODO(blocker) comments) but the current state is definitely reviewable, as most the refactoring changes and tests for new features are already present. I don't expect to change code that's already present while working on the blockers; and I need to take some time to work on other topics anyway

[gagbo]

Since contexts are always immutable objects in Go (to deal with race conditions), the current method to inject the trace ID and the span ID into the context isn't correct.

The method will probably change to add another statement at the top of the function, marked //autometrics:tracing, that will reassign the context when detected, in order to set the SpanID in the context of a function. The TraceID will likely need to be set by a separate middleware library?

At least, it means that there is no need to add code that implements WithTraceID in prometheus/otel, as there's currently no way to make the trace id (injected in autometrics runtime context) available in other calls.