Upgrade to Hadoop 2.2.0, add custom InputFormat and OutputFormat

NOTE: This is still a work in progress. Please do not run/test this as of yet. Wait for my signal. :)

I have set the Hadoop version to 2.2.0 because it has a lot of bug fixes that we need (regarding splittable compression streams) - any version 2.2.0 onwards will be okay.

This PR mainly makes the following changes:

1. Set Hadoop version to 2.2.0 and make certain changes to prevent compile errors (Hadoop API changes?) and move from deprecated API to newer API.
2. A custom InputFormat called `DBpediaWikiPageInputFormat` is added (which uses two classes, `SeekableInputStream` and `ByteMatcher`) that supports compressed input. It also supports **splittable** compression methods like bz2 which is a huge benefit for us. Here's how: say we have this input file, *enwiki-latest-pages-articles-multistream.xml.bz2*. It's > 10GB. It's compressed such that Hadoop's splittable input stream implementations can break it into chunks and decompress them on the fly *parallely*. Parallel decompression and subsequently parallel operations on the data.
3. A custom OutputFormat called `DBpediaCompositeOutputFormat`) is used to write outputs in parallel instead of streaming it over the master iteratively and writing to Hadoop FileSystem - this obviously eliminates a big performance bottleneck. (It's committed, but not actually put to use as of yet. I will update this once I do)

`WikiPageWritable` is a Hadoop `Writable` implementation that wraps a `WikiPage` and handles its serialization/deserialization. Similarly, `QuadSeqWritable` wraps a `Seq[Quad]` - this one is used for writing outputs.

I may update this PR after I test this out on 5-6 languages in parallel today.

Feature-wise we're left with distributed outputs using a custom OutputFormat implementation which should pretty much wrap up **nildev2**. I shall make another PR for that in a day.
write() can be called in multiple workers on the same node, or on multiple nodes, which for our purposes are the same because both involve multiple JVMs. Note that we do not deal with multithreaded execution. The only threading involved is in `DistExtraction` but that's only for submitting jobs and waiting on them.

> Does spark guarantees atomicity?

Could you elaborate? A Seq[Quad] for a particular dataset will be written to the corresponding output split atomically, that's guaranteed, because only one `RecordWriter` writes to only one output split at a time. I think I could even remove the `synchronized` part and it'll still be okay. I'll try that out later though.

Does this help? :)