WL#9764: PERFORMANCE_SCHEMA SERVICE FOR COMPONENTS

Expose the existing performance schema interface as a service,
which can be consumed by components.

Currently calls to the performance schema instrumentation can be:
- not compiled in
- static, for calls from the server itself
- dynamic, using a function pointer, for calls from server plugins.

Calls from server plugins rely on a symbol, (psi_mutex_service, etc),
when invoked from plugins.

This task to is extend the interface to also expose a service,
so that code compiled as a "component" (not as a "plugin") can invoke
the performance schema instrumentation.

Functional requirements
=======================

This task does not provide any functionality
that an end user can see directly in SQL.
There is no externally observable change.

Non functional requirements
===========================

NF-1: Provide a service for mysql_mutex

NF-2: Provide a service for mysql_rwlock

NF-3: Provide a service for mysql_cond

NF-4: Provide a service for psi_cond

NF-5: Provide a service for psi_error

NF-6: Provide a service for psi_file

NF-7: Provide a service for psi_idle

NF-8: Provide a service for psi_mdl

NF-9: Provide a service for psi_memory

NF-10: Provide a service for psi_mutex

NF-11: Provide a service for psi_rwlock

NF-12: Provide a service for psi_socket

NF-13: Provide a service for psi_stage

NF-14: Provide a service for psi_statement

NF-15: Provide a service for psi_table

NF-16: Provide a service for psi_thread

NF-17: Provide a service for psi_transactions

Currently, the performance schema exposes low level interfaces
for the following instrumentation:
- conditions
- data locks (in C++, for storage engines)
- error
- file I/O
- idle
- metadata locking
- memory
- rwlock / prlock / sxlock
- socket
- statements
- stages
- table I/O and table lock
- thread
- transactions

This task adds services interfaces, callable from components,
for the following instrumentation:
- conditions
- error
- file I/O
- idle
- metadata locking
- memory
- rwlock / prlock / sxlock
- socket
- statements
- stages
- table I/O and table lock
- thread
- transactions

In other words, all existing instrumentation interfaces are also exposed as
services, with the exception of data locks.

Rationale for not having a data lock "service" :
- Data locks can not be exposed as is, because services can not use a C++ api.
- Data locks are used only by storage engines, currently INNODB.
  Storage engines are not implemented as components, so there would be no
  calling code using this new service.

In addition to all these new services, the following are also exposed:

- a service for mysql_mutex
- a service for mutex_rwlock / mysql_prlock
- a service for mysql_cond

These services hide completely both the underlying implementation (pthread) and
the underlying instrumentation (performance schema) from components.

Rationale for including these in scope:
- without it, component code could call the **instrumentation** part of a mutex
with a service, but still could not call the mutex implementation **itself**,
because that still require dependencies on mysys.
- so without it, the goal to implement instrumented code in a component can not
be met.