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

I played with the typed traits, and realized that it doesnt help much. Here the points to note. 
- Which implementation of ReceivedBlockHandler will be created is not known at compile time (depends on runtime settings). 
- Users of this ReceivedBlockHandler (that is, ReceiverSupervisor) should treat the metadata returned by ReceivedBlockHandler.storeBlock() as a black box (so as a AnyRef or Any), and not have any implementation specific logic to keep things simple. 

Hence, having type in the trait and returning specific type in each implementation is kind of moot, and downstream code will treat is as AnyRef or Any. Rather it introduces weirdness in some places. Ex. default implementation BlockManagerBasedBlockHandler.storeBlock always return None and hence does not really need a type.