[downloader/fragment] Fix ETA calculation of resumed download

[lightmare]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly
• Put an x into all the boxes [ ] relevant to your pull request (like that [x])
• Use Preview tab to see how your pull request will actually look like

---

Before submitting a pull request make sure you have:

• At least skimmed through adding new extractor tutorial and youtube-dl coding conventions sections
• Searched the bugtracker for similar pull requests
• Checked the code with flake8

In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:

• I am the original author of this code and I am willing to release it under Unlicense
• I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

• Bug fix
• Improvement
• New extractor
• New feature

---

Description of your pull request and other information

When resuming a partially downloaded file with fragment (or derived) downloader, the displayed ETA is wildly inaccurate. This is because the call to calc_eta doesn't subtract the starting partial file size from total and current byte counters.

For example: I have 1000MB out of a 2000MB video downloaded (youtube-dl killed for some reason, e.g. I needed to reboot or download something more important quickly). Later I run youtube-dl again to finish the download and the speed is ~1MB/s. After 5 seconds elapsed, ETA shows 5 seconds remaining, because the rate inside calc_eta is 1005MB/5s (instead of 5MB/5s), and so it predicts the remaining 995MB will be downloaded in ~5s (instead of 995s).

This PR subtracts the starting partial file size from the ETA calculation, and thus makes the ETA somewhat useful when resuming a large partial download.