Before this fix, statistics for the memory instrumentation
were inaccurate, in the following scenario:

At T1, thread A allocates some memory, of size N
At T2, thread A gives ownership of the allocated memory to thread B
At T3, thread B de allocates the block memory, of size N

The event at T1 is instrumented with the performance schema,
and an allocation of size N is counted against thread A.

The event at T2 is not instrumented.
The performance schema is unaware of the memory transfer.

The event at T3 is instrumented with the performance schema,
and a de allocation of size N is counted against thread B.

The problem with this approach is with statistics maintained by thread.

When the same code is executed many times (in a loop with the event
scheduler),
- thread A appears to use an ever increasing amount of memory
- thread B appears to consume an ever increasing amount of memory
- the global statistics for the server diverge.

To resolve this bug, two different fixes are implemented.

Which fix to use depends on the nature of the instrumented memory.

FIX NUMBER 1

For memory instruments that are by nature measuring a global resource,
there is no point in maintaining per thread (and per account, per user, per
host) statistics.

A typical example of such usage are shared, global structures,
like the query cache.

For these memory instruments, the performance schema now supports
defining the instrument with PSI_GLOBAL_FLAG.

For instruments defined as global, the performance schema
only maintains the global memory statistics.

In this case, nothing needs to be done for event T2,
as instrumentation for the allocation (T1) and de allocation (T3)
is enough to maintain everything.

FIX NUMBER 2

For memory instruments that are by nature measuring a local resource,
maintaining statistics per thread is desirable.

In order to do so, the performance schema needs to be told about event T2,
which is now instrumented explicitly in the code.

A new entry point in the instrumentation, PSI_MEMORY_CALL(memory_claim),
is used to instrument the change of ownership of a block of memory.

When a thread in the server allocates a data structure,
starts a child thread, and gives ownership of the memory structure to the
child, the code in the child thread now needs to claim ownership of the
data.

With this added instrumentation, performance schema statistics now
reflect more closely how memory is actually used in the server.

Various claim_memory_ownership() methods are implemented to support this.