feat: upgrade fields to use new JSO hooks

[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@cereal/field-serialiation...BeksOmega:cereal/field-upgrades

The details

Resolves

Work on project cereal
Dependent on #5072

Proposed Changes

Adds implementations of the new JSO serialization hooks to all of the built-in fields. Fields in blockly-samples will be handled later.

Behavior Before Change

Behavior After Change

Reason for Changes

Test Coverage

Added basic tests to ensure that fields serialize correctly. More edge cases are handled by the round-trip serializer tests.

[BeksOmega]

@maribethb I'd like your opinion on this:
Since I removed the default backwards compatible implementations of saveState and loadState from the base field class, we could remove the implementations in the sub classes (except for variable). However, leaving them in has two advantages

1. It's less work if we want to add the backwards compatible implementation back in.
2. We get a tiny bit more type safety via explicit casts.

Do you think it's better lo leave them in or remove them?

[BeksOmega]

@alschmiedt are you cool with leaving the explicit implementations in? or do you think it's better to pull them? See this comment.

Since I removed the default backwards compatible implementations of saveState and loadState from the base field class, we could remove the implementations in the sub classes (except for variable). However, leaving them in has two advantages

1. It's less work if we want to add the backwards compatible implementation back in.
2. We get a tiny bit more type safety via explicit casts.

Do you think it's better lo leave them in or remove them?

[alschmiedt]

I think it is fine in the interim while we are still trying to figure out the best story for backwards compatibility. However, I would add this to the list of things to revisit before releasing. My only problem with keeping it in is we are essentially duplicating this code everywhere, so any change to saveState and loadState would have to be updated in every field.

[BeksOmega]

I think it is fine in the interim while we are still trying to figure out the best story for backwards compatibility. However, I would add this to the list of things to revisit before releasing. My only problem with keeping it in is we are essentially duplicating this code everywhere, so any change to saveState and loadState would have to be updated in every field.

Cool cool, I've added that to my task backlog. I'll get this moved to getValue() and merge this tomorrow!