feat: abstract interactions with archive/store

[upils]

• Have you signed the CLA?

---

This branch introduces a pkgSource struct in the slicer that abstracts package fetching via a closure, replacing the previous direct map[string]archive.Archive lookup. This is needed because packages can now come from either archives or stores, and the slicer's Run function must handle both in a generic way. The closure captures the resolved archive or a store error (until the store is implemented) at resolution time, keeping Run source-agnostic. Store packages are not yet fetchable and return a clear "not implemented" error, with a test covering this path.

This lays the groundwork for implementing store fetching without further changes to the slicer's core logic.

upils#21 implements another approach to solve this, relying on a Source interface and a FetchOption marker interface. This approach seems more convoluted without obvious major advantages.

[upils]

[Note to reviewer]: This struct could be extracted to a dedicated package and exported since in the future this abstraction might be useful in other packages, such as cmd_debug_check_release_archives.go.

[upils]

[Note to reviewer]: If we adopt this approach, PackageInfo should likely be extracted to its own package as it will not be specific to the archive anymore and should also be usable by the future store package. This is slightly tangential to changes of this PR so I deffered this change for now.

[upils]

See #316

[niemeyer]

I'm not completely sure it makes sense to have PackageInfo itself to be extracted to a different package, because by the end of the day an apt package archive has package info data, and this needs to be concretely somewhere. The alternative is that we create a common ground type, but these often end up very messy because the become the union of all needs of all backends. It seems better to extend the approach that we are already pursuing here: interfaces that encapsulate only what actually needs to be common across them.

I'll take this comment to continue into a more general direction: this PR as a whole is playing with the right ideas and going into the right direction, but it's not yet nailing a proper encapsulation and abstraction approach to implement what we must. It doesn't make sense for the slider to be the one defining how to fetch packages and how to fetch stores, by injecting a lambda with custom code for either. The slider is precisely the thing that shouldn't care about the detais, and should instead be calling out in a single way towards multiple implementations.

So again, you're probably in the right ground, but needs some tuning still.

[niemeyer]

I'm not completely sure it makes sense to have PackageInfo itself to be extracted to a different package, because by the end of the day an apt package archive has package info data, and this needs to be concretely somewhere. The alternative is that we create a common ground type, but these often end up very messy because the become the union of all needs of all backends. It seems better to extend the approach that we are already pursuing here: interfaces that encapsulate only what actually needs to be common across them.

I'll take this comment to continue into a more general direction: this PR as a whole is playing with the right ideas and going into the right direction, but it's not yet nailing a proper encapsulation and abstraction approach to implement what we must. It doesn't make sense for the slider to be the one defining how to fetch packages and how to fetch stores, by injecting a lambda with custom code for either. The slider is precisely the thing that shouldn't care about the detais, and should instead be calling out in a single way towards multiple implementations.

So again, you're probably in the right ground, but needs some tuning still.