Add ability to delete a Reusable Block to REST API

[noisysocks]

✨ What this is

This PR simplifies the Reusable Block REST API and adds a DELETE endpoint needed for #3792.

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 the DELETE endpoint that we need 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

📋 How to test

Unit tests are included. No functionality has changed (yet), so regression testing should suffice:

1. Create a block
2. Convert it to a reusable block
3. Rename the reusable block
4. Edit the reusable block

[noisysocks]

cc. @youknowriad @aduth @pento

[youknowriad]

Awesome PR. I like the deleted lines here :)

A bit concerned about the wp/v2/blocks. Existing websites could have registered a blocks CPT with the same name. Maybe we should just document it as a new reserved CPT.

[noisysocks]

Thanks @youknowriad! I created an issue (#4190) to remind us to look into documenting that this could be a breaking change.