feat: track ActiveRecord async queries

[zvkemp]

Fixes #1219.

[Description WIP]

still todo:

• test with async aggregation queries (e.g. #async_count)
• test with multiple concurrent queries (ended up not using any stacks or additional context, so there are unlikely to be issues here).
• I don't love how the span name is derived in FutureResult#execute_query — the Rails authors seem to have just decided to forward arguments as a blob through all of the async stuff; these are re-expanded into named arguments in raw_exec_query back in the connection handler. It's never guaranteed that name will remain the second argument.
  • more on this: unfortunately we also can't guarantee that the query is executed in an otel context that can be propagated from the scheduler method — i.e. we can set the desired span name into the context, which works if the async executor enqueues the task or executes it inline, because we can copy that context into the task. However, if to_a is called before the task is picked up, the query is executed synchronously in the parent span/context. I think it will need to be copied in as an ivar on the future result instead.
• Neither User query (existing otel instrumentation name) nor User Load (ActiveRecord name) follow the semconv guidelines for the span name (the preferred name would be SELECT users, but changing this is probably not the job of this PR. I'll try to at least make this internally consistent for now (edit: fixed to use User query)
• There is one test (the one that calls skip) that demonstrates a false-positive async: true attribute. This false positive should be fixed if possible (edit: calling this a 'wontfix' for now, as it's really a Rails bug).
• Decide whether or not the context propagation here is necessary, or if the concurrent-ruby instrumentation will always be installed when the Rails instrumentation is installed (see [ActiveRecord] Add Attributes for Async Queries #1219)
• is the schedule query span useful at all? Seems like there is a small amount of overhead in getting the async query into the executor and then subsequently running it, so perhaps? There is also the issue that if we include it, it becomes the parent of the async query spans, which may not start before the schedule query end_timestamp (so they are not enclosed by the parent at all).