Templates: Assign default post format block as template setting

[aduth]

This pull request seeks to refactor default block by post format to be effected as a template.

This is being proposed for two primary reasons:

• It is a simplification, reusing existing template mechanisms in place of an additional step for enacting the default post format block
• As an extension of the previous point, it will serve to benefit a planned subsequent refactoring of editor initialization aimed at eliminating "setup" steps of the editor, for which the default post format block is otherwise difficult to mimic in state without a designated start point.

There are two notable differences from how this behaves in master:

• The template is not enacted except when editing a new post.
  • Arguably, I find this behavior, both for the default post format block and templates in general, to be buggy. For example, on master try:
    1. Set default post format to Image on Settings > Writing
    2. Navigate to Posts > Add New
    3. Add a title
    4. Remove the default image block
    5. Save the post
    6. Reload the editor
       • Expected: My changes are reflected (i.e. the removal of the default block)
       • Actual: The image placeholder block returns! Again, I acknowledge this could be an argued as intentional, but to me it seems like the default block should serve as a starting point niceity, but ultimately we respect the user's decisions to manipulate or remove those defaults.
• The default block is no longer inserted when changing Post Format field
  • Another niceity, but I don't find it to be a worrisome change

Testing instructions:

Verify there are no regressions in the behavior of the default block by post format.

Ensure new end-to-end tests pass:

npm run test-e2e

[aduth]

None of these existing "Using a CPT" test cases have been changed. They're simply grouped / nested within a new "templates" describe block.

Edit: Scratch that, while I was here, I normalized to use getEditedPostContent instead of the existing "switch to code editor" logic.

[jorgefilipecosta]

I'm not sure if we should deprecate this selector as it may be a useful selector for plugins, that may want to have a UI based on post formats. We also have a possible use case of this selector, the getSuggestedPostFormat selector. Currently is not using this selector but I think we may do a refactor there to use it instead of removing the selector.

[jorgefilipecosta]

On a second thought, a refactor of getSuggestedPostFormat may not be possible as in this selector we may have multiple blocks mapping to a single post format.
I still think getDefaultBlockForPostFormat may be useful for plugins but If we don't have a use case for it we should not be sending its bytes so probably what we have now is the best option.

[aduth]

I tend to optimize toward avoiding keeping things around because we'd anticipate them to possibly be useful. In this particular case, it's also a heavy maintenance burden to maintain mapping between post formats and default block both within JavaScript and in PHP. If it's something we want in the future, I think it'd be better for us to refactor how we provide it, bootstrapping from some constant (optionally filtered) defined server-side.

[jorgefilipecosta]

I did some tests on the post formats (post init and suggestions) and the tests went well, everything seems to be working correctly. I think removing this system of starting a post with a block already inserted and using the one from templates is a positive change 👍