Inline blocks shouldn't be editable via the normal block content UI

I got this started from the editing side.

With the issue fork, you can add ?edit=UUID-FOR-THE-BLOCK-TO-EDIT, and layout builder will open the right block form on load.

I'm not sure what it will take to link to this, but if we can get contextual links added, it should work.
Looking for feedback on the approach and query parameter name.

I think the ability to edit inline blocks from the front end makes the most sense for UX. I would like to see contextual links that bring up a modal. 90% of the time I'm an admin editing the latest revision and I want to save and create a revision according to the "create revision by default" setting. There may need to be some configuration options, and a confirmation form to make decisions about things depending on what state it's in. It sounds like there are a pile of technical reasons why this is hard, but it would be great to start structuring the basics and work out the edge cases over time.

Should the issue title be changed? I think it should now be "Add contextual link to inline blocks to edit in layout builder".

This issue component is set as block_content.module, but I think this applies to all inline blocks in layout builder.

All these ideas are great, but this issue needs to focus on denying access to edit a block that is reusable from the UI (i.e admin/content/block/IDfor all the reasons explained in #7.

Re #9 I agree we should be open to it, but not as part of this issue. Editors already have the choice of inline vs reusable, they just have to create them in different locations. Perhaps we could have a "convert to reusable" feature or something, but again that's for another issue.

acbramley → changed the visibility of the branch 3075308-inline-blocks-shouldnt to hidden.

Posted an MR with a potential solution. Still needs tests.