Improve handling of parent class loader for generated classes

[mattmarron]

By default, MyClassLoader's parent is beanClass.getClassLoader().

However, if the beanClass is in a different classloader than MyClassLoader.class.getClassLoader(), the instrumented class cannot access BeanPropertyAccessor and the defineClass call fails.

Fixed by simply overridding loadClass, which then looks at MyClassLoader.class.getClassLoader() for any afterburner class.

Added a test (roundtrip?) and ran the full suite. The test I added uses a committed Bean.class file as an example of the error.

[cowtowncoder]

Thank you for submitting this. I must admit that I do not fully understand how class loader interaction fails here (I mean I understand at high enough level, just not interaction between bytecode generation and bean class), but I trust this solves a real problem.
Due to possibility of regression I think this can only go in 2.9.0, but that is due to be released quite soon.

Only one question: where does Bean class itself come from?

[cowtowncoder]

One more thing: will be happy to merge; but one clerical thing: we need a CLA before first contribution.
So unless I've asked for and gotten it already (apologies if so), it'd be this:

https://github.com/FasterXML/jackson/blob/master/contributor-agreement.pdf

and usually easiest way is to print, fill & sign, scan, email to info at fasterxml dot com.
If that could be done, I'll merge the fix in.