Add JSO hooks for blocks and fields.

[BeksOmega]

The basics

• I branched from project-cereal
• My pull request is against project-cereal
• My code follows the style guide

Link for Diff: BeksOmega/blockly@tests/serialier...BeksOmega:cereal/basic-hooks

The details

Resolves

Work on project cereal.
Dependent on #5034

Proposed Changes

Adds saveState and loadState to fields. These functions wrap the old toXml and fromXml functions for backwards compatibility (as suggested by Sam).

Adds saveExtraState and loadExtraState to blocks. These functions do not wrap mutationToDom and domToMutation because mixins don't allow that.

1. If we add default definitions to the block, the mixin function will throw errors when devs try to overwrite it.
2. If we mixin default definitions via the extensions logic then we don't have wrappers for mutators defined via JavaScript.
   As such handling backwards compatibility will need to be done in the JSO serializer itself.

Reason for Changes

We want hooks specific to the JSO system.

Test Coverage

Added tests to make sure the extension system handles the new mutator mixins correctly. I'll add serialization testing when I actually write the serializer.

Documentation

I have a running docs task outside github.

Additional Information

I didn't add hooks for icons yet, because I think that will run into problems with icons not being added in headless mode. I'm going to worry about that after the rest of the serializer is built, because serializing icons is a comparatively small part of serialization.

[BeksOmega]

Note that this doesn't solve for the case where someone is extending a field other than Field and adding custom serialization. For example, pretend FieldVariable is external so new hooks aren't being added to it. FieldVariable extends FieldDropdown and adds custom serialization with toXml. When we go to serialize it using saveState FieldDropdown's saveState function is hit instead of this one on Fiield. Therefore FieldVariable gets serialized as a dropdown field rather than stringifying its XML implementation.

Sadly I don't think this is solvable :/ We can't do any fancy undefined checking like we do with blocks without requiring devs to explicitly implement serialization on every field (even if they want to use the default implementation).

This is why I hate allowing people to depend on the internal class hierarchy lol.

[alschmiedt]

Hmm so what does this mean for external developers? Any custom field that adds logic to the toXml method will need to add a saveState method?

[BeksOmega]

Only custom fields with custom toXml method that extend classes other than Blockly.Field. So if you extend Blockly.TextInput, Blockly.FieldDropdown etc, then yeah you have to add a saveState method :/

I think it may be better to rip the backwards compatibility out for now, and explore providing a python script that will add wrapper implementations to developers' block and field files. That will make make it so that our internal code doesn't rely on Blockly.Xml (making it possible to delete later) and it fixes the above problem. I also mention that option here.

[alschmiedt]

Ok, that sounds fine with me. If we run into any unknown problems with the script we can add this back before releasing.

[alschmiedt]

Nit: XML

[alschmiedt]

Hmm so what does this mean for external developers? Any custom field that adds logic to the toXml method will need to add a saveState method?

[BeksOmega]

Note to self:

• Update style before merging