statistics: add phase-level observability for ANALYZE

## Enhancement

`ANALYZE` can be hard to troubleshoot when it is slow. Today, we can usually see the overall job status and processed rows, but it is still difficult to answer questions like:

- Which part of the ANALYZE pipeline is actually slow?
- Is the bottleneck in TiKV scan, sample/stat merge, local stats building, or saving stats?
- Which analyze options or session variables are likely affecting that part?

It would be helpful to add **phase-level observability** for the ANALYZE process.

### Proposal

Split the ANALYZE workflow into a few **high-level phases** and record lightweight diagnostics for each phase, for example:

- how long the phase takes
- which major parameters may affect it
- a simple summary of the dominant/slowest phase

The exact phase boundaries do not need to be very fine-grained, but they should be enough to distinguish the major parts of the pipeline, such as:

- request / task preparation
- scanning data from TiKV
- merging samples / intermediate results
- building stats in TiDB
- saving stats
- finalization work

### Initial scope

A reasonable first step is to add **structured logs** and/or internal tracing for these phases, so users and developers can quickly see where time is spent.

Later, if this proves useful, the same information could also be exposed in places like `SHOW ANALYZE STATUS` or another system table/status view.

### Expected benefit

This would make slow ANALYZE jobs much easier to diagnose and tune. Instead of only knowing that "ANALYZE is slow", users could get a hint like:

- TiKV scan dominates this ANALYZE
- local stats building is expensive
- saving stats is the bottleneck

This should improve both user experience and troubleshooting efficiency without changing ANALYZE semantics.