[SPARK-4028][Streaming] ReceivedBlockHandler interface to abstract the functionality of storage of received data

As part of the initiative to prevent data loss on streaming driver failure, this JIRA tracks the subtask of implementing a ReceivedBlockHandler, that abstracts the functionality of storage of received data blocks. The default implementation will maintain the current behavior of storing the data into BlockManager. The optional implementation will store the data to both BlockManager as well as a write ahead log.

Is there value to having a shared trait here if you just return `Option[AnyRef]`? Why not just have two types of `ReceivedBlockHandler` that don't share a parent class. The caller cannot interact with them in an interchangeable way anyways, it needs to check the return type.

Also, could you specify the failure handling semantics for these storeBlock methods? Are they supposed to throw an exception on failure?