I needed to update the player css because the editor side wasn't large enough to be useable.

We can't rely on refreshWorkspace always causing a toolbox update, so make sure to update the toolbox manually if it is needed.

Override the z-index for the blocks drag layer. At 1000, it will be over everything in the gui other than the navbar itself (monitors on the stage, tutorials, alerts, dropdown menus, etc.)

This fixes a problem where having a non-default locale set during the initial load would display the blocks in the default toolbox in the wrong language, because the toolbox recycling toggle in setLocale does not work on initial load because there is no editing target to refresh.

Since the common use-case is download/edit/re-upload, and we do not want to explode the storage size of assets (which are considerably larger with fonts inlined), just do what scratch2 did and do not inline the fonts. This is not ideal if kids want to use the costumes for other purposes, but until we can create a way to strip inlined fonts before uploading to the asset server, this is the conservative way to go.

This fixes the issue where you could not see any new variables or custom block callers, as well as fixing the issue where the toolbox did not update from then on.

fixes https://github.com/LLK/scratch-www/issues/2587
and https://github.com/LLK/scratch-gui/issues/4428

changed menu-bar z-index to one more than monitors so drop down menus cover monitors when opened.

This invalidates the toolbox XML when switching back to the code tab after e.g. renaming a costume, making the code tab

Need to store the rendered xml because the props can change while the blocks tab is hidden, but we re-render based on what was rendered, not the previous props (which may not have been rendered).

This is similar to the `ThrottledPropertyHOC` in that there may be prop changes that do not get rendered, but in this case for a different reason.

This increases the performance of switching between code and other editor tabs, as well as improving the "See Inside" performance. It makes switching to the code tab as fast as switching between sprites.

It also avoids repeating the costly object spread, which becomes a problem for projects with a lot of sprites

The fontInliner from the scratch-svg-renderer was changed recently to work entirely on strings, so we can use that instead of parsing/loading/possibly drawing/stringifying the entire SVG. 

This does not address the size-1 cache issue where the cache is invalidated any time there is more than 1 sprite. But that can be handled later.

Using the 4x CPU slowdown in chrome dev tools, on a simple costume that just has a single text element the getCostumeUrl time goes from 10ms to 1ms, very important for updating in a timely way.

Adds unit tests for this HOC.

Use PureComponent instead since it is a simple shouldComponentUpdate check now.

This fixes the root cause of #2858, which is caused because we are rendering the sound editor based on the GUI editing target data, but retrieving the sound based on the vms editing target data. The throttle of the redux action was causing those to get out of sync while a project was running.

The throttle is not needed because the vm runtime already batches those updates at 30 fps. The updates that come from top-level actions like switching sprites go out immediately.

This is also a minor performance boost, because there was a few ms being spent in setting and checking timers that were not needed.

Forcing the playhead onto its own painting layer removes an expensive composite with the waveform. Animate using transforms instead of left prevents layouts of the rest of the page while playing a sound.

The waveform component was being re-rendered while the playhead changed, which is a costly operation because it has to calculate the full svg path data string.

Also use white as the background since it gives the same impact and will not look bad if the filter isn't applied or takes a while to be applied