Always return PrimitiveFloatList, even when cold

[FelixGV]

The PrimitiveFloatList is an API which users should expect to rely on,
so it is wrong to degrade to the more constrained List API while
Fast-Avro is still cold. This commit introduces several changes to make
the extended API reliably present whenever using Fast-Avro, regardless
of being cold or warm.

• Changed PrimitiveFloatList to an interface, in a new package called:
  com.linkedin.avro.api; since the package name migration makes this an
  incompatible change, it would be desirable for the next release to
  not increment only the patch version. Having a proper package name
  for API extension should make things cleaner in the future as we add
  other optimized APIs (e.g. PR PrimitiveGenericRecord interface #45).
• Renamed the old class to ByteBufferBackedPrimitiveFloatList, and made
  it implement the new interface.
• Added new several new classes to ensure that the PrimitiveFloatList
  is always returned even when Fast-Avro falls back to vanilla Avro:
  • ColdPrimitiveFloatList which is a naive implementation that simply
    implements the new API by delegating to the regular Avro functions.
    This does not provide any GC benefits, but at least maintains the
    API.
  • ColdGenericDatumReader and ColdSpecificDatumReader which extend the
    GenericDatumReader and SpecificDatumReader classes, respectively,
    from vanilla Avro.
  • ColdDatumReaderMixIn which provides a utility function to minimize
    repeated code between the two DatumReader functions.
• Significantly refactored the FastGenericDeserializerGeneratorTest so
  that it tests three permutations: vanilla, cold fast and warm fast.
  As part of doing this, several test short-comings were discovered and
  fixed. In particular, the decodeRecordSlow function had some flipped
  parameters which led to test failures on vanilla Avro, and those test
  failures were hidden by the fact that some tests ignored the provided
  permutation param and systematically tested only Fast-Avro.

[volauvent]

LGTM. Curious to know what's the exact performance improvement to cold-mode. Worth a JMH benchmark :-)

[FelixGV]

Actually, there is no performance improvement whatsoever (but there could be some improvements in the future with this method...). The goal of this PR is purely to ensure that the extended API is always provided, even in cold mode.