[#33] Better end-of-sync output

[chshersh]

Resolves #33

This PR changes the fetching algorithm significantly in an attempt to improve the final output. Specifically,

1. Information about assets of all tools is fetched first before downloading the tools. This way users see all validation errors before the downloading has started.

   The only validation errors left are missing exe files in assets, I believe. Or GitHub Rate-Limit error when trying to download an asset.

2. Estimated download size is printed before the downloading (so users can see how much it would take to download).
3. The correct tags are shown immediately.
4. Lots of refactoring.

A single GIF worth a thousand words:

[MitchellBerend]

Im happy that the structure of the fetching and actual downloading is the way it is in this change. It means actual decisions can be made based on the status of tools in the configuration.

This might also enable a prediction about how many of the configured tools can actually be downloaded since there is a rate limit of 60 requests per hour. I think the hard limit we run into right now is 30 tools total. There is 1 api call to find the id of the tag and then 1 call to actually download it.

[chshersh]

It means actual decisions can be made based on the status of tools in the configuration.

Indeed, that's the plan 🙂

This might also enable a prediction about how many of the configured tools can actually be downloaded since there is a rate limit of 60 requests per hour. I think the hard limit we run into right now is 30 tools total. There is 1 api call to find the id of the tag and then 1 call to actually download it.

If you use a GitHub token, the limit is actually 5000 (and not 60). I believe we have some capacity until people need more than 2500 tools 👍🏻

[MitchellBerend]

Turns out my GITHUB_TOKEN had a space in it :sweat:.

[chshersh]

Here is the final GIF after applying suggestions in this PR: