Shared Blocks: Refactor fetching/saving/updating to avoid cycle dependency

[youknowriad]

Related #7075 alternative to #7077

This PR refactors saving/editing/creating shared blocks by removing the uid key we were setting in the state of the shared blocks. This ends up being a big simplification.

This cycle dependency was causing the blocks relying on shared blocks to remount when the associated shared block is refetched from the server.

Testing instructions

• Test creating/editing/converting/inserting shared blocks :)

[mcsf]

This is working well for my simple shared block but not my nested one (see #7075 for screencasts). The window freezes when attempting to add that block, or edit in a post that contains it.

[noisysocks]

This looks similar to how shared blocks were originally implemented in #3017 and #3377. We moved towards the uid pointer approach in #5228 as a way of supporting shared nested blocks.

If we're convinced that uid pointers is an unworkable approach then we might want to consider reviving #5010 which was @aduth's original attempt at supporting shared nested blocks.

[noisysocks]

This does also fix #5754, though! 🙂

[youknowriad]

I see, it's a complex problem :) caused by the fact that we rely too much on the context to access the blocks (unique store), we don't have a component that renders a list of block given this list per prop :(.

I think we can't fix this quickly. I do think there's a conceptual problem with the cycle dependency we have right now because, updating an existing reusable block shouldn't rerender it or regenerate the attached block.