Related: #714
Potentially related: #391

See blocks API documentation for current intended usage of attributes

Thus far we've encountered a few pain points as it relates to initializing block attributes.

1. A block's initial attributes are a combination of explicit markup parsing from hpq matchers and implicitly from values serialized into the comment demarcations. The latter is determined at time of save by comparing the current attributes of a block with those explicitly defined in its attributes. This makes it difficult to determine, at a glance, all of the attributes a block is handling.
2. The attributes property is misleading because it is not intended as a set of values to access, but rather defines how those attributes are to be retrieved
3. We might need a mechanism to provide static (shared reference) default values of an attribute, particularly for complex values. See Text Block: Fix updating the content of an empty text block #512, where destructured defaults in edit resulted in new references on each render, resulting in performance loss by inability to strictly compare. This pull request introduced defaultAttributes. Since then, however, Editable has been refactored to better accommodate an undefined value, so this default may not be necessary at all. Instead, we may want to push block implementers to better handle an undefined value.
4. The attributes property has multiple signatures in order to allow custom parsing by content string. This is rarely used and easy to overlook (see Add tweet block for embedding tweets #754 (comment))

How can we simplify these use-cases to ensure that attributes are obvious to scan at a glance, and avoid confusion around how they're used? One idea that comes to mind is a getInitialAttributes single getter function to rule them all (drawing parallels to React's state initialization), but I've not yet settled on what would be a good set of arguments to pass and source matching behavior to expect from such a function.