Refactor EditorBlock to simplify block registration.

[jmichaelward]

The EditorBlock structure was developed as an initial attempt to capture the basics of what's needed to register a custom block for the WordPress editor. Unfortunately, in its current state, it doesn't meet one of the aims of OOPS-WP, which is to make registration of custom WordPress elements as quick and painless as possible.

After some discussion with both front-end and back-end engineers today, we've come to the conclusion that refinements are needed to streamline this process. The primary changes that are necessary include:

• Establishing a mechanism to automatically register a block based on its name (e.g., block script names are {block_name}-js, {block_name}-editor-css, and {block_name}-style-css)
• Blocks should have sensible default scripts packaged in the automated registration (e.g., wp-blocks, wp-element), with the option to add additional dependencies, similar to how the get_args method of ContentType objects allow for customizations to the narrow defaults.
• All blocks, by default, should register an editor script and editor style.
• Blocks should allow for the inclusion of other array properties allowed by the register_block_type method in WordPress.
• Blocks should automatically detect index.js scripts (instead of block.js) as that appears to be the accepted standard in WordPress. The default editor style should be editor.css.
• Script paths should be overridable to allow for per-project customization, if needed.

In light of these changes, it's likely that this update will break compatibility with the existing EditorBlock contract. If that is the case, then inclusion of this change into the library should result in a full version increase in OOPS-WP.