Dl tracking

This got a bit bigger than I expected, and there is still more I want to do.

Main changes: 
- made `DownloadTrackingService` dumber/simpler
- updated `CompletedDownloadServiceFixture` to test the subject directly rather than through `DownloadTrackingService`
- renamed `DownloadClientId` to `GrabId`
- renamed `TrackedDownloadState` to `TrackedDownloadStage`
- added `History.GrabId`, I'm thinking we should make it an actual column, so dealing with it gets a bit easier, also we would be able to query based on it rather than loading the whole history in memory.

@markus101 @Taloth 

Please test it for 1000+ imported episodes in the download client, and see if the RemoteEpisode lookup doesn't hurt cpu & IO.
It might, it might not, I honestly don't know.
The goal of caching was to be able to quickly identify and ignore those already imported episodes (without db calls).

Anyway, this is broken:
- Download Grabbed & sent to client.
- CDH sees download on api, calls TrackDownload, new instance returned with 2min lifecycle.
- Queue UI fetches from QueueModule, QueueService and GetActive. Proper list is returned.
- CDH cycles, sees download on api, calls TrackedDownload, existing instance returned... still 'time' remaining in lifetime.
- ...
- CDH cycles, sees download on api, calls TrackedDownload, existing instance returned, just before lifetime expires.
- Queue UI fetches again, lifetime expired, Queue UI is suddenly empty until CDH cycles again.
- User complains, someone blames markus, whom tells melfy and then we're all cooked.

Something else, just remembered. Previously, if the user refreshed the UI we would fetch an update of the download client (caching 5 sec), mostly to be able to get update ETA faster than the regular 30sec interval. We would also send a signalr push every 30 sec to get the UI to update.
I'm fine with not doing that 5sec caching anymore, eta isn't that important. Just something that's gone too now.