FSE: Remove template block settings and UI

[noahtallen]

The goal of this PR is to improve the UX of FSE by removing a lot of visual clutter caused by our container blocks. With this PR enabled, you'll see virtually nothing related to them while clicking around! @shaunandrews was definitely right on here.

Here's what it looks like: (lol my gif software speeds it up a ton)

Changes proposed in this Pull Request

• Disable all block settings for the post content block
• Disable anchor setting for template block (custom classname is still needed for @Copons work to make the theme classname available on the top level block)
• Cleanup the CSS for hiding all of the UI related to the post content & template blocks. @apeatling had done a ton of work for the post content block per this, but it turns out that Gutenberg v6.2 introduces some new dashed borders to indicate structure, and we needed to get the CSS ready for that. I also extended this CSS to the template block.
• Make sure that it's impossible to even see the block setting panel for the template block.

Hiding template settings
Diving into that last item, I used a little hack that's available in core. The SiteTitle block actually deselects itself when you click into it (you'll notice you see no block settings when clicking the site title block because of that). So I also applied that to the template block. When you click on it, we just dispatch an action deselecting it. This means that you don't see the settings panel for it. And it's totally transparent, it visually just looks like not much happens when you click on it.

Trying to hide post content settings
I tried to extend this approach to the post content block, but it turns out that when the post content block is deselected, you can't select or edit or do anything to the inner blocks. So that was a no go. This caveat is still there in v6.2, but it turns out they're reverting that behavior: WordPress/gutenberg#16888. I'm not sure there's a ton more we can do unless we want to use a css hack to display:none; that bad boy. It will be really nice if WordPress/gutenberg#7469 gets implemented. Then all of this will be resolved. :)

What does this mean, then? You can still see information related to the post content block in two places.

1. The breadcrumb thingy for blocks shows the parent block in its path.
2. If you select in the area around the post content, it's possible to select the block and see its name in the settings panel. Note that there are no settings that can be changed here, though. Additionally, you have to click twice to begin editing the post content.

Why not fix those now?
I think it would be high effort and low impact, so I figured I'd get a PR up for the rest of it for now. :)

Testing instructions

1. Run FSE on your local environment. Brownie points if you can test this with Gutenberg v6.2!
2. Open the page editor. Click all over the place. Make sure that you see no block UI related to our container blocks other than the mention above.
3. Click into the header and footer areas. Open the block settings sidebar and make sure you see "no block selected"
4. Click and hover around the elements in post content. Make sure you see no outlines of the larger post content block.
5. Make sure that the "edit header/footer" buttons still open the template editor.

This goes a long way towards fixing #34751, but it may not be completely fixed. Need to do some more testing on that.
Resolves #35094.

[matticbot]

Test live: https://calypso.live/?branch=fix/remove-template-block-controls

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[glendaviesnz]

👍 This all works for me, and tested on gutenberg 6.1 & 6.2 and didn't notice any issues.

[Copons]

Works fine for me too, but I've got an additional suggestion.
What about renaming the Content Slot block into just Content and updating the description (#)?
As it is right now, it sounds more technical than descriptive, and would probably be confusing for the end user to see the page blocks being treated as children of a nondescript "content slot".

What do you say if we went with something like this?

- title: __( 'Content Slot' ),
- description: __( 'Placeholder for a post or a page.' ),
+ title: __( 'Content' ),
+ description: __( 'The page content.' ),

(suggestions appreciated for the description, though 🙂 )

[noahtallen]

That's an awesome idea! I think that people won't be confused by that nomenclature if it pops up in a couple of places.

[noahtallen]

Here's what that looks like:

[apeatling]

Tested all of this last night and worked great for me.