SPARK-2621. Update task InputMetrics incrementally

The patch takes advantage an API provided in Hadoop 2.5 that allows getting accurate data on Hadoop FileSystem bytes read.  It eliminates the old method, which naively accepts the split size as the input bytes.  An impact of this change will be that input metrics go away when using against Hadoop versions earlier thatn 2.5.  I can add this back in, but my opinion is that no metrics are better than inaccurate metrics.

This is difficult to write a test for because we don't usually build against a version of Hadoop that contains the function we need.  I've tested it manually on a pseudo-distributed cluster.

getInputBytesReadCallback only gets called once per task - to find the function and return it.  Are you worried about that per-task overhead?  We still do have a single reflective call to actually invoke it when we want to populate the metric.  The internet has a few different opinions on the overhead of this.  Most likely is that it's only about twice the overhead of a direct function call, but I've also seen threads that say it's much more.  Either way, this was my root of my earlier wariness about having this call on the read path as opposed to doing it asynchonously in a separate thread.

On the catch-all exception, you're right - will rework that part.