Allow pinning of start and end dates in query.

We want to allow users to 'pin' the start and/or end date of a
query.

Add options in query.js to allow this.

Note that the start and end dates are only set if the 'period'
parameter is also set: this replicates the existing logic.

Update tests.
Allow grouped_timeseries to pin start/end dates.

Update module, collection, and collection test.
Allow completion modules to pin start/end dates.

Update modules, collection, and collection tests.
Use existing attributes on query change.

This is important for tabbed modules. It ensures that if a start or
end date is set by the initial query, we will continue to use it
on subsequent queries made by other tabs.

The only exception is the availability tabs, which switch period,
and where we therefore want to reset the start date according
to the period.

NB: All this will be superseded by the "tabbable modules" story,
due to be checked in shortly. It is an interim fix.
Allow availability modules to pin end dates.

Update modules, collection, and collection tests.

Don't pin start dates since it's hard to think of a scenario where
this would make sense for this module.
Archive the deposit-foreign-marriage page.

Pin end dates at 30 December 2013.

Update dashboard description to explain that the transaction no longer
exists.

Remove realtime module (since it doesn't make sense to show this) and
journey module (as agreed with Matt).

Remove link to this dashboard from Performance home page.

Pivotal story: https://www.pivotaltracker.com/s/projects/911874/stories/63389134
Show all available data on G-Cloud dashboard.

G-Cloud has data from April 2012 onwards, and the original designs included
all this data.

Pin start date to April 2012 in order to show all available data.
Include data from clock change on no-realistic-dashboard.

The 24-hour availability view now covers the switch from
BST to GMT, so we can easily see if there are any problems.

I've also pinned one of the completion graphs to an end date,
since it seemed like a good idea to include another example
of this on no-realistic-dashboard.
Merge pull request #315 from alphagov/feature/allow-pinning-to-start-or-end-date

Allow pinning to start or end date
Share module rendering and merge view options

We are going to want to share the rendering of modules beyond just the
dashboard controller. The new tab module is built around the idea of is
containing another level of module definitions.

We want the options we pass through to render ending up on the view such
that we can pass through useful properties like, which element to render
into from elsewhere.
Module should expose its visualisation

We need to be able to get at the visualisation contained by a module and
to include such implementation specific code such as
thi.viewInstances['.visualisation'] seemed like madness.
Add TabView

TabView manages the tabs, elements for the different modules to render
into and binds events to swtich between the tabs on click.
Add a TabModule and link it in controller_map

Create a TabModule which uses TabView and the shared module rendering
code to populate the TabView.

We require controller_map as it would create a circular dependency if
placed in the define as TabModule -> ControllerMap -> TabModule.
Styling to work with new tabs
Add new tabs to no-realistic-dashboard
Lint fixes
Added a basic schema for tab modules to allow tab modules to generate json stubs
Listen to model.change event for tab change

Listening to change events on the model allow multiple disparate modules/views to perform tasks on tab click and have awareness of tab state without needing to create a coupling between them.
Fix unit tests
Fix page-per-thing tab view