Many code changes to make everything work with Path and XmlInputFormat. Completes milestone 2.

The existing code works with Files. Hadoop works with [Paths](http://hadoop.apache.org/docs/r2.3.0/api/org/apache/hadoop/fs/Path.html) and [FileSystem](http://hadoop.apache.org/docs/r2.3.0/api/org/apache/hadoop/fs/FileSystem.html) which provide an abstraction over files and file systems. That is to say, Hadoop encapsulates the stuff about distributed or local files and files systems and lets us work with Paths and InputFormats. This pretty much sums up most of the stuff in the commits.

Other than that, I added the XmlInputFormat. I tested with run-extraction-test and everything works. DistRedirectsTest passes. I added some docs too.

Please note that I have taken care to make the commits in a specific sequence. If you make your way from commit 4b9745f to commit d08417f it'll be easier to understand what's going on.

Also, it's worth a mention that you'll need to clone https://github.com/nilesh-c/extraction-framework , switch to the **fromxml** branch and run `mvn install` before building this repo on this branch. I've made a PR to extraction-framework with the changes in **fromxml**.
All right, I think I get it now. I thought that without ```wrapPathStub``` compile errors occurred in code that *uses* ```RichHadoopPath```, but the compiler doesn't accept the *declaration* ```class RichHadoopPath extends FileLike[Path]```. That's because ```FileLike``` is declared as ```FileLike[T <% FileLike[T]]``` and ```wrapPath``` is not an acceptable conversion from ```Path``` to ```FileLike[Path]```. And there *cannot* be a static conversion from ```Path``` to ```FileLike[Path]``` because we don't have a Hadoop configuration at compile time.

You could try to change the declaration of ```FileLike``` to simply ```FileLike[T]```. That should fix this problem, and I think that declaration actually makes more sense because ```FileLike``` itself doesn't need the conversion. I don't know what new problems such a change will introduce though.

If you keep a method like ```wrapPathStub```, I think you should clearly document that it's only a hack to suppress the compile error. You might want to rename it something like ```dummyConversion```. You should also make it private so no code outside the class can accidentally use it, and instead of returning a value it should throw an exception, e.g. ```new UnsupportedOperationException("this method should never be called")```.