Blocks needs a definite compatibility story

I've noticed that if I use newer versions of CodeWorld Blocks to reopen projects built with earlier versions, I often get a bunch of black bits that no longer work. We certainly can't have future development similarly breaking old student code!

It would be great to:
1. Understand what caused this to happen, and
2. Adopt a set of rules or conventions to ensure that we don't break future student projects.

I'm guessing that this comes from renaming or changing XML formats or something like that with previous blocks. That seems to bring up an interesting point: Blockly versions come and go and things change, so it's important that CodeWorld takes ownership of the blocks that it expects to be available, so we can migrate and deprecate them on a carefully controlled schedule. It looks like right now, some of CodeWorld's blocks are built-in to Blockly... and I fear this is the wrong decision.

No files or tests are identified in the issue. Start by tracing how CodeWorld Blocks projects are represented and reopened across Blockly versions, then define the compatibility and migration rules; done means older student projects reopen without broken blocks.

Written by the indexing model from the issue text.