Incorrect user-supplied Avro schema (--avroSchemaFilePath) causes dbeam to produce invalid avro files.

When an Avro user-supplied Avro schema doesn't correspond to actual columns returned by SQL SELECT statement, dbeam produces avro data files, which cause exceptions be thrown when users try to read them.

Identified use-cases

1. Avro schema has less fields than SQL SELECT columns

 * SQL SELECT has columns: COF_NAME, plus many others ...
 * Avro schema has fields: COF_NAME (fewer than expected).
 * This scenario produces an Avro file, which seems to OK,
 * but an exception is thrown when one tries to read it.
 * org.apache.avro.AvroRuntimeException: Malformed data. Length is negative: -50

2. Avro schema has other order of fields than SQL SELECT columns

 * SQL SELECT has columns: COF_NAME, SIZE, TOTAL
 * Avro schema has fields: TOTAL, COF_NAME, SIZE (another order).
 * This scenario produces an Avro file, which seems to OK,
 * but an exception is thrown when one tries to read it.
 * java.lang.ArrayIndexOutOfBoundsException: Index -50 out of bounds for length 2

Start by reproducing the two mismatches described for --avroSchemaFilePath: fewer schema fields and a different field order than the SQL SELECT. Trace the SQL-to-Avro export path and review closed pull request #377 for related context. Done means dbeam no longer produces Avro files that readers reject for either mismatch.