fix: Remove unsafe non-null assertions

[gonfunko]

The basics

• I validated my changes

The details

Resolves

Fixes #9597

Proposed Changes

This PR removes a variety of unsafe non-null assertions in the toolbox.

[BenHenning]

So I think a lot of the changes make sense because they're simplifying existing states. However I'm less certain about some of the other switches to ?. syntax. Some of these seem like cases where the value should absolutely be present. I'm wondering if all of these cases are actually understood as to why the value can be missing. If so, it's definitely worth adding tests and comments to explain those. Otherwise I feel like the forced un-nulling is actually a useful mechanism to catch incorrect developer assumptions (which then leads to overall safety, not just potentially silencing the failure).

What are your thoughts @gonfunko?

[gonfunko]

The main issue here (and throughout Blockly in general) is that lots of things are not actually initialized in the constructor, but rather in some init/createDom method. That means they have to be treated as nullable, but de facto aren't. That's the case here as well; flyout, HtmlDiv, and contentsDiv_ are all initialized by init(), which is called from Blockly.inject(). Being called directly from inject() is about as close to a guarantee of "this will always happen" as we can get, and I think just having ?. to satisfy TS is adequate.

The bug that led to this PR is a bit different in that we do allow adding arbitrary items to the toolbox. We're already only selecting them if they're selectable, so I think only doing that in the case that we were able to successfully look up the item in the first place is fine, and certainly preferable to throwing.