When one session SELECT ... FOR UPDATE and holds the lock, subsequent
sessions that SELECT ... FOR UPDATE will wait to get the lock.
Currently, that event is labeled as `wait/io/table/sql/handler`, which
is incorrect. Instead, it should have been
`wait/lock/table/sql/handler`.

Two factors contribute to this bug:
1. Instrumentation interface and the heavy usage of `TABLE_IO_WAIT` in
   `sql/handler.cc` file. See interface [^1] for better understanding;
2. The balancing act [^2] of doing instrumentation aggregration _AND_
   having good performance. For example, EVENTS_WAITS_SUMMARY... is
   aggregated using EVENTS_WAITS_CURRENT. Aggregration needs to be based
   on the same wait class, and the code was overly aggressive in label a
   LOCK operation as an IO operation in this case.

The proposed fix is pretty simple, but understanding the bug took a
while. Hence the footnotes below.  For future improvement and
refactoring, we may want to consider renaming `TABLE_IO_WAIT` and making
it less coarse and more targeted.

Note that newly added test case, events_waits_current_MDEV-29091,
initially didn't pass Buildbot CI for embedded build tests.  Further
research showed that other impacted tests all included not_embedded.inc.
This oversight was fixed later.

All new code of the whole pull request, including one or several files
that are either new files or modified ones, are contributed under the
BSD-new license.  I am contributing on behalf of my employer Amazon Web
Services, Inc.

[^1]: To understand `performance_schema` instrumentation interface, I
found this URL is the most helpful:
https://dev.mysql.com/doc/dev/mysql-server/latest/PAGE_PFS_PSI.html
[^2]: The best place to understand instrumentation projection,
composition, and aggregration is through the source file. Although I
prefer reading Doxygen produced html file, but for whatever reason, the
rendering is not ideal. Here is link to 10.6's pfs.cc:
https://github.com/MariaDB/server/blob/10.6/storage/perfschema/pfs.cc