eo: rework vtable allocation scheme

eo: rework vtable allocation scheme

Summary:
with this commit a new way of allocating vtables arrived.
The old mechnism was to allocate a table big enough to carry *all*
functions at once, in order to not allocate that much memory for
functions that are not implemented on a specific klass, dichchains have
been used, which can be seens as a 2D matrix, where columns are only
allocated if min 1 entry needs to be written, this may have been a good
way to allocate back in the day when all this with eo started, however,
it showed to not pay off.

With this new way, we allocate a array of arrays. the first lvl array is
carrying enough slots, that *all* up to the time defined
interfaces/classes/abstracts/mixins can be implemented. The second lvl
array then has exactly the size of the defined APIs. The second lvl
array is obviously only allocated if needed.

When comparing the two methods, i messured two things, the usage based
on memory allocation for vtable-way-1 and vtable-way-2. Additionally, i
checked the overall memory usage of elementary_test using pmap. The
first messurement is a little bit more exact. The second messurement is
more biased, but captures the whole picture.

Memory allocation tracking:
   vtable-way-1 - vtable-way-2 = 74680 Byte

Pmap memory tracking:
   vtable-way1 - vtable-way-2 = 217088 Byte

The second messurement shows a bigger impact, likely because this is
also showing off all the sideeffects that we are taking place due to
fewer allocations.

Depends on D11524

Reviewers: zmike, tasn, stefan_schmidt, woohyun, cedric, raster

Subscribers: #reviewers, #committers

Tags: #efl

Differential Revision: https://phab.enlightenment.org/D11535