Optimize the parquet RecordReader implementation when: A. filterpredicate is pushed down , B. filterpredicate is pushed down on a flat schema

The RecordReader implementation currently will read all the columns before applying the filter predicate and deciding whether to keep the row or discard it.
We can have a RecordReader which will only assemble the columns on which filters are applied (which are usually a few), then apply the filter and decide whether to keep the row or not , and then goes on to assemble the remaining columns or skip the remaining columns accordingly.

Also for applications like spark sql , the schema usually applied is a flat one with no repeating or nested columns. In such cases, its better to have a light-weight, faster RecordReader.

The performance improvement by this change is seen to be significant , and is better in case smaller number of rows are returned by filtering (which is usually the case) and there are many number of columns

**Reporter**: [Yash Datta](https://issues.apache.org/jira/secure/ViewProfile.jspa?name=saucam) / @saucam

_{**Note**: *This issue was originally created as [PARQUET-128](https://issues.apache.org/jira/browse/PARQUET-128). Please see the [migration documentation](https://issues.apache.org/jira/browse/PARQUET-2502) for further details.*}

首先定位 RecordReader 的实现及其现有的过滤谓词处理；该 issue 未指定具体的文件或测试。将当前行为与所要求的已过滤列组装以及用于扁平 schema 的轻量路径进行比较，并通过显示预期改进的性能测量来定义完成标准。

由索引模型根据 Issue 内容生成。