[Google Blockly] Only register toolbox callback if we're using the modal function editor

[mikeharv]

Now that we have deleted the unwanted "return" blocks from Sprite Lab - and therefore from Poetry as well (#48895), we can do the same for Dance.

With these blocks deleted in all current/upcoming Google Blockly labs, we can now move some things around related to the toolbox category callback. (Required context: #48545)

Previously, we were using the callback function getFunctionsFlyoutBlocks to customize the blocks that would appear in the auto-populated Functions category. The main difference between our callback and the standard Google Blockly callback (https://github.com/google/blockly/blob/5a23c84e6ef9c0b2bbd503ad9f58fa86db1232a8/core/procedures.ts#L202-L287) was that we were not including "return" blocks. With these deleted, we no longer need to override this call back at all, unless Blockly is going to use the modal function editor.

Fortunately, this previous work wasn't at all a waste of time, because we will still need most of it for the modal function editor.
We already pass in useModalFunctionEditor as an option when we inject Blockly, but so far we haven't been using that information for anything. (In fact, we've updated Poetry and Dance levels to no longer allow setting this property to true, for now.)

I think we can actually use this work to set up some a useful starting point for overriding this category once we do have a modal editor hooked up. We will not use the definition block (procedures_defnoreturn) in these toolboxes, instead replacing it with an orange "Create a Function" button. This is what we are eventually aiming for:

I'm not including screenshots for this PR because there are no visible differences anywhere.

Next steps in the modal editor journey:

• Build a modal function editor (no biggie!)
• Use the Blockly team's upcoming API to move function definitions from the main workspace to... somewhere else. And then move them individually into the modal editor's workspace when it's opened.
• Add an orange "Create a Function" button to the flyout
• Add blue "edit" buttons to function call blocks
• Make the buttons from the previous two points interact with the modal editor.
  Fortunately, none of this is needed any more for the Dance Party flip, but we have a little head start! :)

Links

Testing story

Deployment strategy

Follow-up work

Privacy

Security

Caching

PR Checklist:

• Tests provide adequate coverage
• Privacy and Security impacts have been assessed
• Code is well-commented
• New features are translatable or updates will not break translations
• Relevant documentation has been added or updated
• User impact is well-understood and desirable
• Pull Request is labeled appropriately
• Follow-up work items (including potential tech debt) are tracked and linked

[fisher-alice]

This is great that the work you invested in getFunctionsFlyoutBox and its tests will give you a head start in working on the updated modal function editor!