RuntimeStats for cluster_slow_query

In https://github.com/pingcap/tidb/pull/20200 stats were added for the `information_schema.slow_query` table. However there is nothing for the similar `information_schema.cluster_slow_query` table.

Example:
```
mysql-8.0.11-TiDB-v8.4.0-alpha-364-gd5796776c1-dirty> EXPLAIN ANALYZE SELECT * FROM information_schema.slow_query LIMIT 1;
+-----------------------+----------+---------+------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------+---------+------+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
+-----------------------+----------+---------+------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------+---------+------+
| Limit_7 | 1.00 | 1 | root | | time:1.94ms, loops:2, RU:0.000000 | offset:0, count:1 | N/A | N/A |
| └─MemTableScan_10 | 10000.00 | 64 | root | table:SLOW_QUERY | time:1.93ms, loops:1, initialize: 25.8µs, read_file: 912µs, parse_log: {time:1.78ms, concurrency:15}, total_file: 1, read_file: 1, read_size: 4.05 MB | only search in the current 'tidb-slow.log' file | 1.25 MB | N/A |
+-----------------------+----------+---------+------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------------------------------------+---------+------+
2 rows in set (0.00 sec)

mysql-8.0.11-TiDB-v8.4.0-alpha-364-gd5796776c1-dirty> EXPLAIN ANALYZE SELECT * FROM information_schema.cluster_slow_query LIMIT 1;
+---------------------------+---------+---------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------+------+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
+---------------------------+---------+---------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------+------+
| Limit_7 | 1.00 | 1 | root | | time:2.89ms, loops:2, RU:0.515024 | offset:0, count:1 | N/A | N/A |
| └─TableReader_12 | 1.00 | 1 | root | | time:2.89ms, loops:1, cop_task: {num: 1, max: 2.8ms, proc_keys: 0, copr_cache_hit_ratio: 0.00, max_distsql_concurrency: 1}, rpc_info:{Cop:{num_rpc:1, total_time:2.75ms}} | data:Limit_11 | 2.70 KB | N/A |
| └─Limit_11 | 1.00 | 0 | cop[tidb] | | | offset:0, count:1 | N/A | N/A |
| └─MemTableScan_10 | 1.00 | 0 | cop[tidb] | table:CLUSTER_SLOW_QUERY | | | N/A | N/A |
+---------------------------+---------+---------+-----------+--------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------------+---------+------+
4 rows in set (0.00 sec)
```

Note the `initialize: 25.8µs, read_file: 912µs, parse_log: {time:1.78ms, concurrency:15}, total_file: 1, read_file: 1, read_size: 4.05 MB`

This is generated here: https://github.com/pingcap/tidb/blob/2e51209f483bb7909be1eb0b55e5f18f0c437a25/pkg/executor/slow_query.go#L1115

For the `cluster_slow_query` table you can see that there are no stats:
https://github.com/pingcap/tidb/blob/2e51209f483bb7909be1eb0b55e5f18f0c437a25/pkg/executor/memtable_reader.go#L592-L594

What the stats could show:
- Number of files read
- Number of nodes involved
- CPU usage
- Time
- Memory usage
- Read bytes
- Read number of entries
- Concurrency

Most of these could be per-node, in total or both.