fix: have rendered blocks render themselves on construction

[BeksOmega]

The basics

• I branched from develop
• My pull request is against develop
• My code follows the style guide
• I ran npm run format and npm run lint

The details

Resolves

Work on #5146

Proposed Changes

Makes it so that BlockSvgs automatically render themselves when they are constructed.

Reason for Changes

Before this change external devs needed to call initSvg and render on their blocks if they were instantiating them via workspace.newBlock. But I deprecated render recently. This makes it so calling render is no longer necessary.

Test Coverage

Tested that loading the spaghetti code, and instantiating via newBlock both worked as expected.

Documentation

N/A

Additional Information

I decided to have these queue the render instead of rendering immediately. External devs calling render currently will trigger the immediate render, so this is non-breaking. And this way they can properly switch to using finishQueuedRenders.

[maribethb]

This change itself seems fine, but it seems like #5146 still has more work to be done but this PR says it closes it. For example, you did not remove the TODO comment on the initBlock function in serialization/blocks. Which makes sense, because in #5146 you said you want to refactor the serialization system so that it does not need to do checking based on whether the block is rendered or not. Are you still planning on addressing that? If not could you remove the todo comment and if so could you update this PR so it doesn't say it's closing that issue?

Also, there are a lot of places in core where we still call initSvg and then render / queueRender. Are you planning to update those as well? If not in this PR, could you file an issue for that if one doesn't exist?

[BeksOmega]

This change itself seems fine, but it seems like #5146 still has more work to be done...

Ah yeah you're right, I should have marked this as "work on", not closing. I'm planning to punt on fully cleaning up initBlock because I don't fully remember why the updateDisabled or onLocationChange calls are necessary.

Also, there are a lot of places in core where we still call initSvg and then render / queueRender. Are you planning to update those as well? If not in this PR, could you file an issue for that if one doesn't exist?

Gosh darn it :P I was trying to do too many things at once yesterday. I checked for references on devsite but not other places in core haha.

So still need to:

• Clean up references to initSvg and then queueRender in core.
• Clean up references to initSvg and then render in other parts of this repo.
• Clean up references to initSvg and then render in samples.

Please tell me if there's anything I'm forgetting again!

[BeksOmega]

This ran into problems because having the constructor call initSvg and queueRender means we can end up in a state where initSvg has been called but rendered is false. Our life cycle does not expect this to happen and it causes bugs.

So we're going to refactor rendered first and then make this change.

That means that for v10.1 I'm going to open up a different PR dedeprecating render.