zoomToFit is broken when workspace has no scrollbars and blocks have negative coordinates

[picklesrus]

zoomToFit calculates the incorrect blocks bounding box size when there are no scrollbars and blocks with negative coordinates.

If metrics.contentLeft and metrics.contentTop are negative (which happens when blocks are placed up and to the left of the initial 0, 0 of the workspace), the blocksWidth and blocksHeight calculations are incorrect and the blocks are above or left of the visible area. So, there are two issues at play.

1. https://github.com/google/blockly/blob/master/core/workspace_svg.js#L1414 adds padding to the bounding box to ensure blocks are centered after the zoom is applied, but this only works if blocks are at positive coordinates.
2. There's currently no way to get blocks at negative coordinates into the frame.

Note that this isn't a common problem for a user to run into because most workspaces that have blocks in the negative coordinate space also have scrollbars. The only other way to get them there is to put them there programatically. This was noticed while working with multiple workspaces on a minimap demo (#924).

In order to solve both these problems we will probably need to either move all the blocks to originate at 0,0 or translate the workspace so that the top and left most edges are inside the view.

[alschmiedt]

Closing as this looks like it was fixed in #2247.