Switch runtime codegen from Javassist to ByteBuddy

With the recent rework of runtime-generated code (MDSAL-442, MDSAL-443, MDSAL-401), the shape of these classes ends up not containing any real logic as most of it is held in superclasses (CodecDataObject, CodecOpaqueObject and DataObjectStreamer). We are also in complete control of loading the resulting bytecode and class lookup by virtue of using CodecClassLoader.

Thus we are at a point where Javassist is providing us with no real value and its programming paradigm (i.e. the need to load class bytecode before being able to operate on it) is actually hurting us – see DataObjectStreamerBridge.

Switch to ByteBuddy, whose bytecode-oriented nature allows us to operate on java.lang.reflect-based constructs and emit pure bytecode without intermediate compilation. This should not only streamline our code by not having to deal with CtClasses, but also speed up startup (by virtue of no Exception-driven compilation in Javassist) and lower memory footprint (by virtue of not needing CtClass caches).