Moving relative data logic

Code was moved from parse_request_args() to the Query class's create() and parse() methods. This is in anticipation of the skip-blank-value functionality which will create new query objects if the response contains blank values.
Adding 'skip_blanks' as a valid query parameter

We need this parameter so we can specify that we want to skip the first blank results
Implementing skip blank result functionality

We need this so that graphs on the client side won't have empty spaces where there weren't any results.
Code reverses results before checking first one
Moved skip blank code to query and removed arg

This code should not be in what is essentially the controller layer, so it should be moved to backdrop.read.query. Also, the skip_blank arg was removed as blank values should always be skipped when relative dates are used.
Only calculate start / end in one place

It is being calculated in Query.create this change makes use of that.
Refactor relative date shifting

Create a new identical query with a different 'date' rather than filling
in the missing data. Results in querying for more data but is a simpler
flow because the second query is identical save for the date.
Convert day start fields to datetime in steps
Add day start fields to licensing fixture.
Do no reverse data when skipping blanks
Added skip blank functionality for grouped queries

The skip blank functionality should work for all types of queries that can use relative date ranges.
Refactor skipping of blank periods

Moved the logic to calculate how many periods a result should be
shifted into the response module. Each result class controls how it is
shifted so that the Query class can be greatly simplified.
Always tear down bucket in setup_bucekt validator

Exceptions were causing the bucket config to be left around.
Require start / end at if doing a period query

This is the requirement and what the error message is claiming but not
what the validation is checking. Spotlight always performs queries with
a time range so this should not cause a problem.
Add validation for when period is in request args

It doesn't make sense to have a period query without both start and end, or a grouped period query with a limit.
Remove Python 2.6 from build matrix

While it is useful to advertise the versions that backdrop does not work
with I think this can be done in a better way than a travis build that
runs every time but always fails.
Merge pull request #232 from alphagov/remove-python-26

Remove Python 2.6 from build matrix
Use start_at/end_at + duration for relative ranges

This replaces the date and delta arguments.

Relative date range queries now look like this: "/foo?start_at=DATETIME&duration=POSITIVE_INT&period=day"
Add monthly (+25%) monitoring for *_sales datasets

So that gcloud_sales is monitored once more.
Merge pull request #230 from alphagov/monitor-gcloud-sales

Add monthly (+25%) monitoring for *_sales datasets