[WIP] Add ability to delete a reusable block

[noisysocks]

✨ What this is

This PR does a few things so as to close #3792 and close #4041.

🌱 Simplify WP_REST_Blocks_Controller

At first, our API looked like this:

• GET /gutenberg/v1/reusable-blocks — fetch all blocks
• GET /gutenberg/v1/reusable-blocks/:uuid — fetch a single block
• PUT /gutenberg/v1/reusable-blocks/:uuid — create or update a block

We then switched to using IDs instead of UUIDs, which made our API look like this:

• GET /gutenberg/v1/reusable-blocks — fetch all blocks
• GET /gutenberg/v1/reusable-blocks/:id — fetch a single block
• POST /gutenberg/v1/reusable-blocks — create or update a block
• PUT /gutenberg/v1/reusable-blocks/:id — create or update a block

Look familiar? That's the same as our API for viewing and modifying regular posts!

In this PR, I switched the base class of WP_REST_Blocks_Controller from WP_REST_Controller to the less abstract WP_REST_Posts_Controller. This lets us remove a lot of boilerplate, and gives us a DELETE endpoint for free.

I also took this opportunity to implement three smaller changes regarding the name of these routes:

1. I've changed the name of the resource from reusable-block to simply block. This corresponds nicely to the name of our registered block type (core/block) and the name of our custom post type (wp_block).
2. I've moved the namespace of these REST endpoints from gutenberg/v1 to wp/v2. This means we can remove this annoying hack that I never liked, and should make things smoother for us when Gutenberg is eventually merged into Core.
3. I've renamed the name attribute in the resource to title. Blocks are custom post types: they have titles, not names.

Our API now looks like a very regular REST endpoint:

• GET /wp/v2/blocks — fetch all blocks
• GET /wp/v2/blocks/:id — fetch a single block
• POST /wp/v2/blocks — create or update a block
• PUT /wp/v2/blocks/:id — create or update a block
• DELETE /wp/v2/blocks/:id — delete a block

🗑 Add the ability to delete a Reusable Block

With the above changes, this is pretty straightforward:

1. There's a new DELETE_REUSABLE_BLOCK effect which calls the destroy() method that the WP API Backbone library gives us for free.
2. This effect optimistically calls REMOVE_REUSABLE_BLOCK which actually removes the block from local Redux state. If the delete fails, REMOVE_REUSABLE_BLOCK is reverted.

💆‍♀️ Improve the Reusable Block flow

I implemented the changes suggested by @karmatosed in #4041 by moving 'Detach Reusable Block' into a seperate settings menu section alongside our new 'Delete Reusable Block' button.

Here's how the settings menu now looks for a static block:

And here's how it now looks for a reusable block:

📋 How to test

1. Create a block
2. Convert it to a reusable block
3. Rename the reusable block
4. Edit the reusable block
5. Use the Inserter to insert a copy of the reusable block
6. Remove a block
7. Delete the reusable block

🚧 What's left to do

• Remove the core/block blocks from the post when a reusable block is deleted
• Replace my window.confirm with something better

[noisysocks]

Going to split this PR up as it's a bit too large.