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.
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 in quick Query internals explanation
Adding comment for first_nonempty()
Merge branch 'skip-blank-values' of github.com:alphagov/backdrop into skip-blank-values
Adding comment to PeriodQueryValidator class