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

@andrewor14 , since the `effectiveStorageLevel` only used for forcing a MEM_AND_DISK partition to disk in this patch, is it better not to expose this parameter here and in `BlockManager.putBytes/putArray/putIterator`. Because if someone explicitly give an `effectiveStorageLevel` by calling `BlockManager.putBytes` directly for example [PR#3534](https://github.com/apache/spark/pull/3534), and the effectiveStoragelLevel  might be different from the original `level` (cache levels and replication), this will lead to some wrong messages on webUI, because the BlockManager is not aware of this.

Take another case for example, if original Level is MEM_ONLY, and the user force it to cache on disk via effectiveStorageLevel, then the BlockManager will never know the block is on disk, and the block will be a zombie. Of course , such case would not likely happen.