workspacesView: Remove spacing

It's not used in the theme and it complicates the layout code a bit
too much; in fact, if set, things start breaking.
workspace: Punt the geometry-fizzling-out logic here
overview: Send the clone with the window-drag events

This allows clients that care about the actual item we're dragging to
make smarter decisions without adding a drag monitor themselves.
workspacesView: Don't do any special handling for item-dragging

The code here really only cares about new windows.
workspacesView: Don't use a drag monitor to get the clone

Just use the new variable passed to the signal.
workspacesView: Don't zoom into the overview based on a signal

Instead, simply have somebody else call us, like we do for hiding
the overview as well.
workspacesView: Don't tween the upper of our scroll adjustment

This really doesn't make sense. The new upper should be the new workspace
index as soon as it's available.
workspacesView: Make each WorkspacesView own its set of workspaces

Right now, the workspace update code is complex and spread across parts:
WorkspacesView takes a set of workspaces and looks like it owns them, but
WorkspacesDisplay is actually in charge of setting them up and creating
new ones for each WorkspacesView.

Change initialization and handling to move all of the creation/destruction
responsibilities to WorkspacesView.

We pass in monitorIndex into each WorkspacesView, which is a lie in the
workspacesOnlyOnPrimary case, as the primary WorkspacesView currently has
the responsibility of handling the extra workspaces on all the other
monitors. The commit will clean this up and punt the responsibility back
to WorkspacesDisplay.
workspacesView: Simplify the workspacesOnlyOnPrimary implementation

Before, workspacesOnlyOnPrimary was implemented in quite a crazy manner:

 * If workspacesOnlyOnPrimary was false, we'd create one WorkspacesView per
   monitor, with the primary one being a bit special.

 * If workspacesOnlyOnPrimary was true, we'd create one WorkspacesView, and
   additional montiors would be handled inside that WorkspacesView as
   "extra workspaces".

This caused numerous bugs as the two modes weren't consistently
implemented, and a lot of code was duplicated between all the modes.
Fix this by always creating WorkspaceViews, even if it only handles
one interface. We do this by having two different WorkspacesView-ish
classes: WorkspacesView handles the traditional combination of lots
of workspces, and a new ExtraWorkspaceView is in control of only one
workspace.