Add binding/dom codec class loader support

Add binding/dom codec class loader support

Our current codec implementation relies on creating classes in
classloaders holding compile-time-generated code, effectively
polluting them, in two distinct ways.

The first, less intrusive, is the instantiation of dynamic
proxies, which support LazyDataObject and ForeignOpaqueObject
instances. Since this is done via JVM interfaces, the JVM
takes care of reusing these classes, but still they cannot
be removed when the binding-dom-codec is unloaded -- fortunately
their nature of being derived from yang-binding and compile-time
generated interfaces allows them to be reused.

The second, more intrusive, is the instantiation of dynamic
streamers to support emitting NormalizedNode structures from
DataObject instances. While there are some provisions to reuse
them, they are inherently tied to how BindingRuntimeContext
interprets generated classes -- if the underlying SchemaContext
ends up interpreting them incompatibly (for example, by leaf
changing to anyxml), we end up between a rock and a hard place --
the classes do not match NormalizedNode world and they cannot
be reloaded to rectify the problem.

This patch adds the infrastructure for separating out compile-time
and run-time worlds by introducing StaticClassPool and
CodecClassLoader. StaticClassPool is used to bind Javassist code
generator to the classloader into which binding-dom-codec is loaded.

CodecClassLoader allows effective bridging of StaticClassPool and
whatever classloader is loading compile-time-generated classes,
and provides a place where new classes can be defined without
polluting either classloader.

Change-Id: I963c7bc6eefd5dd77a80e06442896265116664c0
JIRA: MDSAL-442
Signed-off-by: Robert Varga <robert.varga@pantheon.tech>
(cherry picked from commit 57c0721d7660c83dadf2194923d75f7e4d664b7e)