optimizer trace should also support Prepare statement and Execute statement.

## Enhancement

Sometimes, we can always tell from the slow-log file whether a query **A** is from the cached plan or not.

Since it has existed in the slow-log file, there must be some performance problems with them, for example, **rewriting time-consuming**, **optimization time-consuming**, or even **execution time-consuming**. The third one is not about Plan-Cache's businesses because the non-prepared statement should have the same execution time-consuming problem as well. We mainly talk about the first two cases.

We may easily hear that one's compile-time is not as expected, taking up **X** hundred milliseconds or so in plan cached cases：
* step 1: For the most intuitive decision is to cache that plan again.
* step 2: Then the second intuitive action is to figure out **Why does compile time takes up such a large human-perceivable proportion**. (maybe some resource bottleneck can be detected, or a workload burden)

This enhancement can help with the second step here.