Add OptimizationBegan query lifecycle event

[ggevay]

Adds the OptimizationBegan event to the query lifecycle, as mentioned in the Lifecycle design doc.

Note that this should be very close in time to ExecutionBegan if things are behaving correctly. However, I have reason to believe that this is not always the case: Some time ago, the OptimizationFinished event used to have a bug where it was actually showing what the new OptimizationBegan event will be showing, and looking at a certain user's lifecycle history from before fixing the bug, there were sometimes multiple seconds between ExecutionBegan and the buggy OptimizationFinished.

After this PR is rolled out to users, we should check whether it is still happening that the beginning of optimization is sometimes far from ExecutionBegan, and if yes, then debug.

Motivation

• This PR adds a known-desirable feature, see design doc: Design doc on extending the query lifecycle tables #32504

Tips for reviewer

Checklist

• This PR has adequate test coverage / QA involvement has been duly considered. (trigger-ci for additional test/nightly runs)
• This PR has an associated up-to-date design doc, is a design doc (template), or is sufficiently small to not require a design.
• If this PR evolves an existing $T ⇔ Proto$T mapping (possibly in a backwards-incompatible way), then it is tagged with a T-proto label.
• If this PR will require changes to cloud orchestration or tests, there is a companion cloud PR to account for those changes that is tagged with the release-blocker label (example).
• If this PR includes major user-facing behavior changes, I have pinged the relevant PM to schedule a changelog post.

[ggevay]

Moving back to draft, as people are concerned about the scalability of the lifecycle builtin tables.