Optimize the PacketRegistry using a vtable like approach. This vtable
approach should be implemented as a generic vtable library:

Every class which shall be extensible needs to inheriv from the vtable
base class. This base class adds an integer member to the class. This
baseclass uses the CRTP pattern to initialize this integer to a type
specific value.

To get theese values, we use a typeid registry. The typeid-registry is
a tempalte struct with the class as template arg and a single static
member fn. This fn has a member variable of type 'typeid sequence
value'. The constructor of this type will automatically allocate the
next free typeid integer. This can then efficiently be returned by the
static retrieval function:

    template <class T>
    struct senf::vtable::impl::TypeRegistry
    {
        static unsigned id() {
            static senf::vtable::impl::AutoTypeId typeid;
            return typeid.id();
        }
    };

    struct senf::vtable::impl::AutoTypeId
    {
        AutoTypeId() : id(nextAutoTypeId()) {}
        unsigned id;
    };

    unsigned nextAutoTypeId()
    {
        static unsigned id(0);
        return id++;
    }

This setup will assign id's uniquely. The Id's will be ordered by the
first TypeRegistry::id() call. To get the Type id of a type, just call
senf::vtable::impl::TypeRegistry<SomeType>::id().

The above is bogus ... we don't register the extensible types, we
register the extensions which are arbitrary types.

The typeid assigned to the extension type is used as an index into a
vtable. This vtable is in the simplest case, just an std::vector of
void*. To assign an extension to a specific type, we just add some
instance of the registered extension type to the vtable of the
to-be-extended type using the slot given by the typeid of the
extension type. To get the extension, we just look up the id of the
extension type and cast the value from the vtable vector to the
appropriate type. All this is O(1) and does not depend on the number
of extensions or on the number of extended classes.

The extension vtables are created inside a static method of a
templated class (template arg is the extensible class). Additionally,
the extensible class must CRTP-wise inherit the vtable baseclass,
which will add a vtable pointer to the extensible class and initialize
it automatically to point to the correct vtable.

To make this even more efficient, all vtables should be kept in a
list. This allows to keep all vtables to the same size. Then no range
checking must be done on accessing the vtable, since all vtables are
all as long as the largest extension id. This of course makes the
Operation of registering a new extension type O(n), but that should
not be a problem since extensions are registered once during program
startup. As a reward, the lookup performance is increased: it is only
a memory access to find the extension-type id(the address is fixed at
compile time) followed by an indexed access to the vtable, where the
vtable address is fetched using another memory access. This differs
from a compiler-generated vtable access only by a single memory
access.