Separate history server from history backend.

This change does two things, mainly:

- Separate the logic of serving application history from fetching
  application history from the underlying storage. Not only this
  cleans up the code a little bit, but it also serves as initial
  work for SPARK-1537, where we may want to fetch application data
  from Yarn instead of HDFS.

  I've kept the current command line options working, but I changed
  the way configuration is set to be mostly based on SparkConf,
  so that it's easy to support new providers later.

- Make it so the UI for each application is loaded lazily. The
  UIs are cached in memory (cache size configurable) for faster
  subsequent access. This means that we don't need a limit for
  the number of applications listed; the list should fit
  comfortably in memory (since it holds much less data).

  Because of this I lowered the number of applications kept in
  memory to 50 (since that setting doesn't influence the number
  of apps listed anymore).

Later, we may want to provide paging in the listing UI, and also
spilling the listing to disk and loading it on demand to avoid
large memory usage / slow startup.
Rudimentary paging support for the history UI.

The provider's list api was tweaked a little bit so that the caller
can get an atomic view of the data currently held in the provider.
Ensure server.stop() is called when shutting down.

Also remove the cleanup code from the fs provider. It would be
better to clean up, but there's a race between that code's cleanup
and Hadoop's shutdown hook, which closes all file systems kept in
the cache. So if you try to clean up the fs provider in a shut
down hook, you may end up with ugly exceptions in the output.

But leave the stop() functionality around in case it's useful for
future provider implementations.