Schema Evolution RecordBatch processor

[sdd]

Addresses parts 2 and 3 of #405.

Add support for type promotion and default values to the read pipeline.

• When the scan includes fields that have undergone type promotion since some of the underlying parquet files were written, any selected fields that have undergone type promotion will be promoted to the newer type before being returned to the user. For example, A table contained a field "a" that was a Float, and some rows were written. The table's schema was changed so that field "a" is now a Double. When a table scan is performed, record batches coming from files written prior to the type promotion will be dynamically converted so that field "a" is of type Double, matching any row batches returned from files written after the schema change.
• When the scan includes fields that have been added since some of the files were written, record batches will be dynamically converted as per the above to contain selected fields that were not present at the time the file that they were in was written. These will have a value of null if there is no default value present for the column but the column is not required. If the table schema specifies an initial-default-value for the field, then all rows will have that value for the new column instead.
• If any fields have been renamed, the record batch schemas for rows written before the rename occurred will be rewritten to contain the new field name.
• If projected_field_ids is provided, the columns in the response will be re-ordered to match the order in the projection.

[sdd]

I need to go back to the drawing board on this. The current implementation breaks when not all columns in the file are in the list of projected fields.

[sdd]

OK, I've addressed the problem with projections other than the equiv of SELECT *. All existing tests passing, and new tests extended to cover these cases.

[sdd]

@liurenjie1024 and @Xuanwo - ready for review when you get chance