Download: add a 'resume' option

[fingolfin]

An interrupted download starts again from zero, with no option to resume. This can be really annoying if one just managed to download 95% of a huge file but then the transfer was interrupted.

With resume := true and target given, the via curl and via wget methods continue the partial file, and a failure keeps that file so the next attempt can carry on.

Methods that cannot resume decline rather than proceed, to make sure they don't destroy the partial file.

If no resuming method is available the download fails and the caller can retry without resume.

Written with Claude Opus 5 via Claude Code.

CC @ThomasBreuer

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.46%. Comparing base (3db5598) to head (048a61b).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #105      +/-   ##
==========================================
+ Coverage   86.33%   86.46%   +0.12%     
==========================================
  Files          32       32              
  Lines        1910     1928      +18     
==========================================
+ Hits         1649     1667      +18     
  Misses        261      261              

Files with missing lines	Coverage Δ
lib/download.gi	94.17% <100.00%> (+0.51%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[cdwensley]

@fingolfin Be sure to tell me when these four (or more?) PRs are ready to be merged and a release made.

[fingolfin]

Last week I was a conference and went a bit overboard with allowing my AI to open PRs without me double checking everything. That was a mistake and I apologize if I wasted anyone's time by having them stare at slop. (The "reviewed by me" was inserted by the AI without consulting with me -- but I should have caught it. Argh).

Anyway: I've marked this PR as "draft" for now, please don't merge it -- I'll carefully review and edit it, and will mark it as "ready for review" once I am satisfied. Don't waste your time on it for now (that said, of course you are welcome to leave feedback, but don't feel obliged to).

[fingolfin]

I think this should be ready for a human review now; perhaps @ThomasBreuer could have a look?

[ThomasBreuer]

Concerning the intended resume functionality, I have no objection.

Besides that, the more I think about what we really want, the more questions arise.

The current situation is that we call Download and prescribe a local filename name via the target component of the optional record.

• If we do not specify resume:= true and if the Download result reports failure, should Download always try to remove the file name before returning its result?
  (Currently the wget based method calls RemoveFile and even signals an error if this removal fails; I think the behaviour should be the same for all available methods.)
  If Download does not promise this removal, then should we say in the documentation that it is the user's responsibility to remove name after a failed download?
• Suppose that there is already a file name before the Download call, perhaps different from the file one wants to download.
  If we do not specify resume:= true, should Download try to remove the old file before calling its methods? (If yes then what shall happen if this removal fails?)
  Or can we expect that each method will overwrite a perhaps existing file, and that each method will report success only if the old file was overwritten?