Save and Load sb3 projects

[kchadha]

Proposed Changes

Save button (when manually enabled) downloads a zip containing:

• the project's JSON
• serialized sounds
• serialized costumes

For sounds and costumes, this should include any edits made in the sound/costume editor respectively.

Load button (when manually enabled) should take in a zip that was previously downloaded via the save button, and the project should load and sounds and costumes should be up to date.

These changes depend on scratchfoundation/scratch-vm#964, and should not be merged until after that PR has been merged.

Reason for Changes

Towards a working SB3 Save and Load implementation.

Test Coverage

Existing tests pass, but integration tests for saving and loading need to be added in the near future.

Changes to come

• Projects should save as '.sb3'
• Compress downloaded projects
• Remove unnecessary calls to storage caching (this includes implementing an indication that an asset is dirty, checking if loading locally vs. from server as a way of pre-emptively deciding whether assets should be cached to storage from imported file or if we should lookup the asset in the webstore)
• Remove duplication of asset metadata between vm and storage (this includes duplication of information in 'assetId' and 'md5' properties. Tracking these in two different ways causes bugs and confusion.
• Allowing 'load' to load .sb2 and .sb files (filter out all other file extensions from the file system browser).
• scratch-vm#194 & validation of project json based on sb3 spec

[cwillisf]

Similar to my comments on scratchfoundation/scratch-vm#964, I think the jszip dependency should be in scratch-storage. Is that your plan in the long run?

The code looks good to me, other than that concern.

[kchadha]

@cwillisf, I agree with removing the JSZip dependency from scratch-gui, as it's not strictly necessary. In regards to moving the JSZip dependency out of scratch-vm and into scratch-storage, I think that means that scratch-storage will have to keep the unpacked zip assets around until vm is done deserializing the project (and vm will subsequently make requests to scratch-storage to fetch the assets it needs). When the VM is done deserializing, it can tell storage to get rid of the zip. I think this way, we can make sure that storage is not doing unnecessary work of decoding extraneous files, and is also not storing large files forever. How does this sound?

[kchadha]

@cwillisf, I removed the JSZip dependency out of here. VM now unpacks the zip for the short term. I will eventually move this functionality into scratch-storage if my above comment sounds like a good plan. =]

[cwillisf]

Sounds good. Thanks!

[rschamp]

This looks great, thanks @kchadha!