Clarify Timeouts and make HTTPClient timeout configureable

[Eizock]

Renamed Timeout in RequestConfiguration to ConnectTimeout, as this value only applies to establishing a connection—not the full HTTP request/response cycle.
Source

Renamed Timeout to BlockTimeout, since it refers to the timeout for a single block.
After further contemplation, we should probably call it ChunkTimeout.

Added HttpClientTimeout to control the timeout for an entire HTTP request.
Not sure how useful this is, as it overlaps with BlockTimeout.
I’d also be fine setting HttpClient.Timeout to BlockTimeout instead and removing the HttpClientTimeout option.
But we should make this configurable in some way (see below).
Feedback on this is welcome.

I noticed this issue while debugging downloads that exceeded 100 seconds (the default value of HttpClient.Timeout).
Regardless of how I set the two existing timeouts, the request always stopped after 100 seconds.
We could consider writing a test for this, but I’m not very experienced with writing tests.

[Eizock]

I recreated the error:
Exception thrown: 'System.Threading.Tasks.TaskCanceledException' in project.dll
WorkerDownloader: Error: The request was canceled due to the configured HttpClient.Timeout of 100 seconds elapsing.
WorkerDownloader: Error: at WorkerDownloader.DownloadFile(ProgressBar bar, projectDBContext _projectDB, DownloadService downloader, String fileDownloadFSPath, DownloadFile file, projectFileDB projectDBFile, InMemoryLoggingProvider logger, ILogger debugLogger) in c:\Users\Code\Documents\Sourcecode\project\project\WorkerDownloader.cs:line 184
WorkerDownloader: Error: Exception: The operation was canceled.
WorkerDownloader: Error: InnerException:[null]
Leaving this here for completeness sake.