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.

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
;)

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.

remove TimeSlotManager and use them as functions

Closes: #155

Closes: #155