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 

There is a check here that automatically enables it for new installs (those which not yet configured a drone factory).(https://github.com/Sonarr/Sonarr/blob/develop/src/NzbDrone.Core/Datastore/Migration/051_download_client_import.cs#L26)
And there is is a HealthCheck instructing existing users to migrate.

Back then, markus came with a couple of known setups CDH would break. (back then we didn't have path mapping at all). We didn't want to auto-break such setups.

That worst case scenario is interesting, I can't figure why that wouldn't work. I must be missing a scenario somewhere but until I remember I have to concede, it would probably not harm if we enable it by default.

Ah, right, CDH will attempt to import old existing history items. (which is why we instruct migrating users to use a different category.)
I could come up with some far-fetched scenarios in which old history items might still have their files potentially re-importing deleted episodes, but that's so utterly unlikely, I can't bring myself to use that as argument. :P

Anyway if you enable it by default, you should tear out that piece of code in the migration and that part of ImportMechanismCheck.
The ImportMechanismCheck has to be updated too, coz atm it says it doesn't support remote setups. But we can leave that for another time.

If markus can't come up with a reason why we shouldn't, enable it by default.