fix(program-generation): fix undefined behaviour around start and end query parameters

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 query parameters given by the client. However, they cannot expect the actual radio program (in the form of Timeslot objects) to fit these artificial 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 parameter but end after it
• or end after the specified end query parameter but start before it.

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

Example (some input and output attributes shortened for brevity):

Given the following timeslots:

Timeslot(id=1, start="2024-07-23T23:30", end="2024-07-24T00:30")
Timeslot(id=2, start="2024-07-24T06:00", end="2024-07-24T07:00")
Timeslot(id=3, start="2024-07-24T23:00", end="2024-07-25T01:00")

And the following request:

GET /api/v1/program/basic/?start=2024-07-24T00:00&end=2024-07-24T23:59

The output looks like this:

[
  { "start": "2024-07-24T00:00", "end": "2024-07-24T00:30", "timeslodId": 1 },
  { "start": "2024-07-24T00:30", "end": "2024-07-24T06:00", "timeslodId": null },
  { "start": "2024-07-24T06:00", "end": "2024-07-24T07:00", "timeslodId": 2 },
  { "start": "2024-07-24T07:00", "end": "2024-07-24T23:00", "timeslodId": null },
  { "start": "2024-07-24T23:00", "end": "2024-07-24T23:59", "timeslodId": 3 }
]

Contra point:

The start and end attributes of program entries created from timeslots no longer match up with the timeslot’s start and end attributes IF the timeslot wraps around the specified start and/or end query parameter. One might argue, that the start and end attributes of program entries should always align with existing timeslot start and end attributes.

However, I argue that this is fine because

• these values don’t need to align (they are attributes of distinct models after all),
• it may otherwise cause confusion, because these values might start and/or end before/after the specified start/end query parameters,
• clients might not be interested when a timeslot has started or ended, but need to know the duration of the program entry in the specified range
• and because clients can still get these values from the associated timeslot object.