slicer/test: Support for custom packages

[woky]

Currently we only test with the embedded base-files files package. This
quite limits what we can test. But since commit a3315e3
("testutil/pkgdata: Create deb programatically") we have the ability to
define our own custom package content.

Add support for testing with custom packages. These can be defined in
each test case per archive name. The content can be defined directly in
test case definition with the help of testutil.MakeTestDeb().

The package content is wrapped in the testPackage structure. This
introduces one level of nesting in each test case package definition. In
future, we will add package metadata to the package definition, namely
version. So wrapping the package content in the structure now and later
just adding a new field to it the structure later will make the future
diff much smaller.

[woky]

This PR depends on #86.

[rebornplusplus]

I think this only depends on #86 now?

[cjdcordeiro]

I think this only depends on #86 now?

I think so too, and thus it is worth merging them given how small #86 is

[rebornplusplus]

Only reviewed 83e83eb. It looks good to me, except the comment about names I put in below.

[woky]

I think this only depends on #86 now?

I think so too, and thus it is worth merging them given how small #86 is

Yes, this now depends on #86. But #86 is different feature, so I'm not really sure if I should merge it.

[cjdcordeiro]

I think this only depends on #86 now?

I think so too, and thus it is worth merging them given how small #86 is

Yes, this now depends on #86. But #86 is different feature, so I'm not really sure if I should merge it.

It can be rebased now though, since the 1st commit is already on main

[niemeyer]

Neither in the type definition nor here do we have a hint of what these strings actually mean. This also seems slightly misleading because the testPackage is actually a slice here, isn't it? No, it's a deb. So it's archive and packages.

We have @rebornplusplus above hinting as this issue too. I'm not sure his suggestion is the best idea either, but it would be nice to make things slightly cleaner. Any suggestions?

[woky]

@niemeyer I've applied @rebornplusplus's suggestion and in the end, I like the result. The definition now looks like:

	summary: "Custom archives with custom packages",
	archives: map[string]testArchiveData{
		"leptons": testArchiveData{
			packages: []testPackageData{{
				name: "electron",
				content: testutil.MustMakeDeb([]testutil.TarEntry{
					Dir(0755, "./"),
					Dir(0755, "./mass/"),

I've made archive packages a list instead of a map because one archive can in theory contain packages of the same name with different versions and/or architectures. It also reduces one level of indentation.

Note that there's also testArchive structure which implements Archive interface. That's why I suffixed the new structures with Data, though I admit it's kind of a fallback naming...

The changes are in a new fixup commit. Does it look better now?

[letFunny]

Per our offline discussion, I think our best way forward is to close this PR and discuss with @rebornplusplus to see if it is a priority right now, and how to amend the code here to make it compatible with the latest changes. We will take that discussion offline and we can always re-open the PRs or create new ones as we see fit.