Order talks consistently by track per time slot

[iansltx]

This is probably easier to do as an API change (might move the issue over there if I start working on it and find that this is the case) but when viewing talks in the list view on e.g. a four-track conference, for two slots where all four tracks are occupied, the third talk in the list for each slot should correspond to the same track, vs. relying on talk insertion order (which gets extra messy for subbing in talks later).

Eventually we'll want to allow specified order for tracks. But relying on track insertion order (AKA PK) should be sufficient for now, as tracks take less elbow grease to create than talks.

[iansltx]

Looks like this will be slightly easier to perform in this repo as a quick fix; there's an N+1 going on in the talk list for grabbing tracks so it's not really any more efficient to sort talks by track (which is a 1:M somehow) API-side than client-side.

Just checked the database and we actually only ever have one track associated per talk, though some talks have a track ID of 0 multiple times. So we could actually pull the track ID into the talk model as an ?int, cleaning up both existing data and querying in the process.