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

Personally, I specify Option in the variable name, because it because it make it easier to read code like `somethingOption.getOrElse`.  Otherwise, if I see `something.getOrElse` I have to track back and see whether `something` is a HashMap or Option. And errors like not calling `get` or `getOrElse` when the actual value is necessary become more immediately clear.

Again, this is a not a very strong logic, just a personal preference of mine.

Regarding consistent naming, if that code is within the scope of the lines that I touch in the PR, I will fix it.