API consumers must not be tempted to parse ids, so we encode them as
UUIDs to prevent that.

Up until now the id of the first and last program entry was based on the
filtered range. Instead, we want these to be based on the first timeslot
that was scheduled before/after the specified range. This way we ensure
that the ids of these entries are stable as long as the schedule doesn’t
change.

Mapping keys in filter_data are guaranteed to be defined but might be
None for boolean filters. We want to ensure that we actually pass
booleans to generate_program_entries.

This flag allows clients to define what they expect as default behaviour
for setting the ProgramEntry start and end attributes.

If the flag is set steering ensures that ProgramEntry.start never starts
before the requested start and that ProgramEntry.end never ends after
the requested end.

We might need that queryset unbothered by already set filters later on
;)

This new endpoint allows clients to easily purge steering’s application
state. It is primarily designed for use in integration tests as outlined
in aura#387.

The endpoint is available in debug mode so that developers can inspect
the schema. However, any request to it is denied unless the
OPERATING_MODE environment variable is set to "tests". This is a
precaution for administrators that use the debug mode to analyze
application issues in production.

ValueError has no built-in handling in DRF causing it to return an HTML
error page. This is unfortunate for clients that expect a JSON error
object like the dashboard.

The radio program is a continuous stream of program slots. Clients can
expect that the program generated for their queries fit the start and
end parameters given by the client. However, they *cannot* expect the
actual radio program (in the form of Timeslot objects) to fit these
artifical boundaries.

As the program endpoint should always output the actual program
broadcasted by the radio we must include timeslots that
  * have started before the specified start query but end after it
  * or end after the specified end query but start before it.

The changes in this commit ensure that the program matches the given
range exactly and that planned timeslots in that range are always
included.

This makes it easy to list entries with specific ids, which comes in
handy when clients want to fetch multiple known objects at once.