Reorganize core supported blocks into top-level blocks directory

[aduth]

This pull request seeks to explore a restructuring of blocks to colocate implementations with the API in an effort to provide better control mechanisms over when and how blocks are enabled in an editor. In subsequent pull requests, this will be expanded to revise behavior of registration such that a block will no longer automatically be enabled as an option in all cases, but rather made available in a bucket of all known block types from which the editor can cherry-pick.

Potential cases where this may be useful:

• Filtering blocks by post type
• Filtering blocks by role
• Filtering blocks by custom plugin logic
• Filtering blocks by editor type (in case of future site building efforts)

The idea being that all core blocks are always registered, and a server-side-filtered array of desired block slugs will be provided for the editor at initialization time.

[aduth]

Need to sort through a failing test at editor/test/state.js, likely related to recursive dependencies. Speaks to a more general concern about how exactly we should handle dependencies within and between directories.

[aduth]

That we can't destructure query here is a little disappointing. Might be worth a rethink on exporting hpq as wp.blocks.query, either renaming the property or simply assuming dependent plugins refer to hpq directly.

[youknowriad]

We should probably merge this asap to avoid conflicts. The changes look good for me. Curious to know how did you fix the tests? Is it the transform-runtime removal?

[mtias]

Yes, let's get this in. Thanks @aduth :)

[aduth]

We should probably merge this asap to avoid conflicts. The changes look good for me. Curious to know how did you fix the tests? Is it the transform-runtime removal?

Yes, there's some more detail in the extended description of a71bea2. I'm still not entirely sure why the runtime polyfill works fine in the browser but not in Node.