[Avro] Remove dependencies upon Jackson 1.X and Avro's JacksonUtils

[baharclerode]

This is the first half of a fix for #167

This removes the references to Jackson 1.x and JacksonUtils (which is internal to Avro), allowing Jackson-Avro to be binary-compatible Avro 1.9 or Avro 1.8 but not semantically-compatible in all cases, particularly around nested classes; For simple use-cases, this is sufficient to allow Jackson-Avro to work with Avro 1.9, but I would not by any means call it "supported" due to the nasty gotchas that still lurk.

This does not provide full backwards and forwards compatibility with Avro 1.9; Notably:

• Generating a schema using Jackson-Avro w/ Avro 1.9 will still produce a 1.8 schema for nested classes; Avro 1.9 can't use these for serialization (But Jackson-Avro w/ Avro 1.9 can). Deserialization still seems to work.
• Uses of the @AvroAlias annotation to create aliases to nested types will break, since previously these had to follow the Avro 1.8 conventions for namespacing nested types
• Mixing of Avro 1.8 and Avro 1.9 anywhere is right out. You can't generate a schema with Avro 1.8 and have Jackson-Avro w/ Avro 1.9 do anything with it if nested classes are involved, and vice versa. The same goes for using Jackson-Avro w/ Avro 1.8 to generate schemas and Avro 1.9 to serialize/deserialize, and vice versa. Don't try it. If it works, it'll work just long enough for you to forget about it not supporting nested classes.

Fixing of the above will probably require porting all of the Avro union resolver code into Jackson-Avro with modifications to allow it to resolve both 1.8- and 1.9-styled namespaces, and a mapper flag that indicates if you want 1.8 or 1.9-compatibility for @AvroAlias annotations and generated schemas.

[cowtowncoder]

Thanks! I'll make a minor post-merge change probably to isolate use of ObjectMapper, but other than that it's the first big step.

[cowtowncoder]

Merged; did some minor renaming.

[cowtowncoder]

Turns out I had to do some more tweaking in 3.0, to avoid breaking #145. Not sure if similar "null masking" might be needed for 2.x, come to think of that (that is, when converting from NullNode, should use JsonProperties.NULL_VALUE, to retain "explicit null as default" vs "no default value).