WL#7777: Integrate PFS memory instrumentation with InnoDB

Account all memory allocations in InnoDB via PFS using the interface provided by
"WL#3249 PERFORMANCE SCHEMA, Instrument memory usage".

Introduce a new mechanism for allocating memory in InnoDB and replace all
current calls to "new" and "ut_malloc()" with it. It will do the tracing via
the PFS mechanisms.

From user perspective no changes, except more entries will appear in
performance_schema tables:

| memory_summary_by_account_by_event_name              |
| memory_summary_by_host_by_event_name                 |
| memory_summary_by_thread_by_event_name               |
| memory_summary_by_user_by_event_name                 |
| memory_summary_global_by_event_name                  |

Translation table from old code to the new mechanism:

1.
Foo*	f = new Foo(args);
or
Foo*	f = new(std::nothrow) Foo(args);

is replaced with:

Foo*	f = UT_NEW_NOKEY(Foo(args));
(will default to event_name like memory/innodb/dict0stats based on the
file name) or
Foo*	f = UT_NEW(Foo(args), mem_key_dict_stats_index_map_t);
(will use a custom event_name defined in ut0new.h for the key)

2.
Foo*	f = new Foo[16];
or
Foo*	f = new(std::nothrow) Foo[16];

is replaced with:

Foo*	f = UT_NEW_ARRAY_NOKEY(Foo, 16);
or
Foo*	f = UT_NEW_ARRAY(Foo, 16, key);

ut_allocator must be supplied to std::* containers as a custom allocator.

3. For example:
std::vector

is replaced with:

std::vector >

and objects of this type are created like:

std::vector >	v;
(will default to event_name memory/innodb/std) or
std::vector >    v(ut_allocator(key));
(will use a custom event_name defined in ut0new.h for the key)

Since the PFS code requires the caller to provide (key, size) to the memory-free
accounting method (not only to the one that accounts the allocation) this data
must be stored somewhere. It can be stored either in a global variable or at the
start of each allocated memory. The global variable is cleaner but requires an
access regulation by a rwlock or mutex. The start of each allocated memory does
not require that but is hackish. This WL will use the second approach.