server: SpanStats architectural improvements

Originally mentioned in #103957, I'm making a separate issue for these comments, so that 103957 can be closed.

- the “new” code for the stats-for-span function is deeply embedded in the obs API server, which is architecturally unsound since the functionality is a pure KV function and should be usable from SQL without interfacing with the API server at all.
- we want to have a version of this code that is guaranteed to operate on a consistent view of the entire span (i.e. not a mix of cached data for part of the span, and uncached for another part)
- we want the API to be able to reuse an existing client.Txn object (instead of synthetisizing its own)

Jira issue: CRDB-29949

Epic CRDB-25476