[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.

The logic here actually hasn't changed (the code was just moved elsewhere). For the `MEMORY_ONLY` case, if we can't be sure that there is enough memory to unroll the block, we simply drop it on the spot. I don't believe this is a violation of the StorageLevel contract insofar as old blocks cached as `MEMORY_ONLY` can also be dropped from the cache. The only difference here is that we drop it earlier (before it has the potential to cause an OOM).

Among the options you listed, the last thing we want is (3), which unfortunately is what happens in the existing code. It's true that if we our estimate is too high, we may drop a block that can otherwise be cached. However, the whole point of this is to guarantee memory safety (i.e. to avoid OOMs), and to achieve that we need to err on the safe side.