Discussion: Should we move generators to blockly-samples?

[cpcallen]

While discussing #7084, #7085 and #7086 with @rachel-fenichel, she wondered whether the proposed changes were going to be disruptive enough to warrant taking the same approach we have with procedure blocks and with some fields: publishing the new version as a plugin in blockly-samples and leaving the existing implementation in core untouched for the time being, to allow developers a more protracted period of time to migrate their code before the old version is ultimately removed.

Arguments in favour:

• Avoids breaking any existing generator code for the time being.
• Publishing the generators we provide as plug-ins provides a useful model for how external developers can publish their own.

Arguments against:

• Proposal: CodeGenerator per-block-type generator function dictionary #7084 proposes a breaking change to CodeGenerator in core/generator.ts; this file would have to be duplicated in blockly-samples (and the breaking change made only to that copy); there would then be two incompatible versions of this file / class, possibly causing much confusion.
• There has been some discussion of moving fist-party plugins from blockly-samples back to blockly, so moving generators to samples seems likely to become a wasted effort.
• Trial implementation of the main proposals suggest that in most cases we can provide at least short-term backward-compatibility for most existing custom generator functions with minimal effort.

[cpcallen]

Since #7084, #7085 and #7086 are now implemented in core, I'm going to close this as moot.