Rewrite the interface of `Target` for encapsulation.

Limiting direct access to the members of Target lead to a lot of discoveries about the organisation of Downloader and zck data and functions, which is why this commit is quite bigger than initially expected. 😬 Some code have been moved from Downloader to Target member functions as they are mainly manipulating the state of Target without much changes to Downloader, which basically is a sign that it's code related to Target.

This is really just side effects of trying to make the Target interface more contained. Because a lot of other code was manipulating it's internals directly, it ended up touching a lot of code. Where possible I tried to keep the order and meaning of the code when I had to move it around.

More info and discoveries (to help lead the related PRs that will come soon):

There is multiple accidental data structures hidden in Target, most related to different aspects of a download process.
This makes difficult to follow which states Target can take and when (there is also a lot of redundancy in how Target's state is changed).
Target, Downloader and zck data/functions are intertwined in a way that suggests there is a several separation necessary (but I didn't proceed where I didn't need to, for now) - basically this lacks "separation of concerns" and should be improved.
Both Target and zck seems to be internal details of Downloader's mechanisms, which is fine, but it also means we should not expose them as public interfaces (I think, or at least not completely).
Downloader::check_msg seems to have at least 3 transfer error flags that might be contradictory; this makes difficult to understand which flag means what kind of error.

All this will probably participate to complications in evolving libpowerloader, but we are in a good position and time to improve the situation. :)

mamba-org / powerloader

Rewrite the interface of `Target` for encapsulation. #124