Separation of concerns: Download client adapters should include the logic to poll completed downloads

[T4g1]

The code from DownloadMonitorService hardcode adapters and pooling logic. Each adapter specific pooling method should be moved to the corresponding IDownloadClientAdapter implementation instead

Note that I'm currently rewritting the handling of adapters as part of #465 and thus will probably replace the hardcoded switch from PollDownloadClientsAsync method there as it allows to query the NET dynamic injection thing to fetch adapter based on an implementation enumeration

Also, the pooling logic might be simplified by using specific adapters's GetItemsAsync (or replacing method GetQueueAsync for which implementation does not seems ready yet) and comparing those to pooled downloads instead of querying them directly from the pooling method

[T4g1]

Here are the features implemented through adapter polling:

• UpdateDownloadProgressAsync: Update progress percentage mostly (which somewhat also does adapter/listenarr download status mapping but should probably not)
• HandleFailedDownloadAsync: Mark a download as failed and removes it from download client too
• FinalizeDownloadAsync: Handle completed downloads, importation mostly
• Persistence: Update CanMoveFiles/CanBeRemoved metadata: This should probably be delegated in another method too
• BroadcastCandidateUpdateAsync: Notify API users that download status has changed (so UI update in other words)

First thing that I see is that BroadcastCandidateUpdateAsync could probably be handled through DownloadMonitorService if specific adapter polling methods returns a list of updated Downloads
Same for persistence: That list of updated download could be enriched with various metadata too

[T4g1]

UpdateDownloadProgressAsync could also be moved to DownloadMonitorService and rely on Download class (with progress and remaining as class attributes)