[SPARK-1940] Enabling rolling of executor logs, and automatic cleanup of old executor logs

Currently, in the default log4j configuration, all the executor logs get sent to the file <code>[executor-working-dir]/stderr</code>. This does not all log files to be rolled, so old logs cannot be removed.

Using log4j RollingFileAppender allows log4j logs to be rolled, but all the logs get sent to a different set of files, other than the files <code>stdout</code> and <code>stderr</code> . So the logs are not visible in the Spark web UI any more as Spark web UI only reads the files <code>stdout</code> and <code>stderr</code>. Furthermore, it still does not allow the stdout and stderr to be cleared periodically in case a large amount of stuff gets written to them (e.g. by explicit `println` inside map function).

This PR solves this by implementing a simple `RollingFileAppender` within Spark (disabled by default). When enabled (using configuration parameter `spark.executor.rollingLogs.enabled`), the logs can get rolled over either by time interval (set with `spark.executor.rollingLogs.interval`, set to daily by default), or by size of logs (set with  `spark.executor.rollingLogs.size`). Finally, old logs can be automatically deleted by specifying how many of the latest log files to keep (set with `spark.executor.rollingLogs.keepLastN`).  The web UI has also been modified to show the logs across the rolled-over files.


You can test this locally (without waiting a whole day) by setting  configuration `spark.executor.rollingLogs.enabled=true` and `spark.executor.rollingLogs.interval=minutely`. Continuously generate logs by running spark jobs and the generated logs files would look like this (`stderr` and `stdout` are the most current log file that are being written to). 

```
stderr
stderr--2014-05-27--14-37
stderr--2014-05-27--14-47
stderr--2014-05-27--15-05
stdout
stdout--2014-05-27--14-47
```

The web ui should show logs across these files.
This was to guard against those remote corner cases where multiple rollovers may occur within the same millisecond (rolling over by size, can occur multiple times within 1 ms, if rollover size is low). This may not practically occur, but an extra "--0" suffix safe guards against that while keep the names semantically useful (time of log in the name of the log is useful).

We could use nanoseconds... and then the format can be either
`stdout-NNNNNNNNNNNN` (not semantically useful name) or 
`stdout-YYYY-MM-dd--HH-mm-ss--NNNNNNNNNNNNNNNN` (semantically useful, but ugly in my opinion).

That still does not deal with some corner cases. What if you are rolling over by size, and multiple rollover occurs within the same millisecond? This is to safeguard against those corner cases as well, as we dont want logs to be overwritten (i.e. lost) at any cost. And 

The good thing about this approach is that