What problem does this PR solve?

Issue Number: ref #57147

Problem Summary: The statement summary tables are the current mechanism we have for collecting cumulative metrics about the execution and performance of SQL queries. However, these metrics aren't truly cumulative: they are refreshed at a regular interval, meaning the cumulative metrics collected for queries are reset, and their previous values are made accessible via a separate history table. For the workload repository, we want to be able to snapshot cumulative metrics aggregated over the lifetime of a TiDB instance, which the statement summary tables do not easily provide.

What is changed and how it works?

• The statistics captured by the statement summaries for each interval have been factored out into a new struct, stmtSummaryStats, that each statement summary interval (stmtSummaryByDigestElement) now uses instead. The struct is embedded so existing field accesses continue to work as-is.
• In the statement summary struct itself (stmtSummaryByDigest), add a new "cumulative" set of statistics (i.e. another stmtSummaryStats struct).
• Create a new memory table, information_schema.tidb_statements_stats, that uses the same stmtSummaryRetriever as the statement summary tables.
• Modify the column factories for the statement summary rows reader to accept an additional stmtSummaryStats parameter. For the existing statement summary tables, this parameter is the stmtSummaryStats struct embedded in the stmtSummaryByDigestElement (i.e. the same values as before). For the new cumulative statement stats table, this parameter is the cumulative stmtSummaryStats struct in the stmtSummaryByDigest. The column factories then read from this stmtSummaryStats parameter, rather than the stmtSummaryByDigestElement struct directly, thus making them polymorphic and able to work for both the cumulative and statements summary tables.
• Add a cluster-wide version of the statement stats table: cluster_tidb_statements_stats.

(The diff for this PR is pretty large, so I'd recommend reading each individual commit one at a time, since they build on each other incrementally.)

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

- Started tidb-server.
- Ran one query, e.g. `select 1;`.
- Verified that a row appeared for this query.
- Re-ran the query several more times.
- Verified that the cumulative stats in that row updated accordingly.
- Verified that the corresponding row in cluster_tidb_statements_stats updated accordingly.

Side effects

• Performance regression: Consumes more CPU
• Performance regression: Consumes more Memory
• Breaking backward compatibility

Documentation

• Affects user behaviors
• Contains syntax changes
• Contains variable changes
• Contains experimental features
• Changes MySQL compatibility

Release note

Please refer to Release Notes Language Style Guide to write a quality release note.

Add a new system table `INFORMATION_SCHEMA.TIDB_STATEMENTS_STATS` to provide cumulative metrics about the execution and performance of SQL queries on TiDB nodes.