Update block API docs with edit/save argument as props

[aduth]

Related: #335
Related: #327 (comment)

This pull request seeks to update API docs for blocks to account for changes in edit and save function argument signature in the blocks API. These property values are now treated as components, accepting props if defined as a function (optionally defined as a wp.element.Component class).

Open questions:

• Is the difference between edit, save accepting a single object vs. encodeAttributes and control's onClick, isActive obvious enough? The latter set of functions have not yet been implemented and are subject to change, but it's not likely they'll be ever be considered as components like edit and save.
• How should we recommend naming the prop argument? Most notably this affects ES5 implementations, as ES2015+ object destructuring avoids need to name the argument. For now I've used block, though props is more accurate (should we shield developers from this terminology?).

On the up-side, passing block/props/options as a single object argument allows us to room to grow if we decide we need to pass more behaviors to the block render.