[SPARK-1777] Prevent OOMs from single partitions

**Problem.** When caching, we currently unroll the entire RDD partition before making sure we have enough free memory. This is a common cause for OOMs especially when (1) the BlockManager has little free space left in memory, and (2) the partition is large.

**Solution.** We maintain a global memory pool of `M` bytes shared across all threads, similar to the way we currently manage memory for shuffle aggregation. Then, while we unroll each partition, periodically check if there is enough space to continue. If not, drop enough RDD blocks to ensure we have at least `M` bytes to work with, then try again. If we still don't have enough space to unroll the partition, give up and drop the block to disk directly if applicable.

**New configurations.**
- `spark.storage.bufferFraction` - the value of `M` as a fraction of the storage memory. (default: 0.2)
- `spark.storage.safetyFraction` - a margin of safety in case size estimation is slightly off. This is the equivalent of the existing `spark.shuffle.safetyFraction`. (default 0.9)

For more detail, see the [design document](https://issues.apache.org/jira/secure/attachment/12651793/spark-1777-design-doc.pdf). Tests pending for performance and memory usage patterns.


If the case is, no matter which node in cluster, the iterator cant be cached - then I concede your point : but this patch does not enforce that assertion.

You are assuming that if it cant be cached on node1, it cant be cached in any other nodeX in the cluster. The OOM might not be necessarily due to the size of the iterator in question, but also due to other data hosted on that node.
So this is not equivalent but a change in behaviour.

Also note that when we drop blocks from an rdd, we never do that for the current rdd - just "earlier" rdd : here, we just dont cache the current iterator at all.

Particularly for iterative algo's, dropping blocks from "earlier" RDD might be fine - but not caching current can result in repeated recomputation down the lineage : which can be prohibitively expensive (we are not talking in face of failures btw - just normal computation).