feat: openkal-musl 0.3.1 and sbase 0.1.1 — a manifest a consumer can resolve - #225

…resolve

openkal-musl 0.3.0 named the implementation of openkal for each system by a
path. That is right in a working tree that has the repositories side by side and
wrong in a package: a path names a directory that exists where the manifest was
written and nowhere else, so a consumer resolving 0.3.0 from this index was
handed a dependency pointing into the registry's own store.

    error: path dependency 'openkal-linux'
           (at '.../xpkgs/mcpplibs-x-openkal-musl/0.3.0/openkal-linux')
           has no mcpp.toml

0.3.1 names it by version, with the feature beside it, because a program above
that library carries no other runtime and that is what the feature states. sbase
0.1.1 is the same package above the version that resolves.

The defect was found by the step this chain has for exactly this purpose:
resolving the package the way a stranger would, from a store with every local
copy deleted. A working tree masks every mistake in a manifest's dependencies,
because the tree is what the manifest was written against.

0.3.0 and 0.1.0 stay in this file. They resolve, they are consistent in both
regions, and what fails about 0.3.0 fails after resolution rather than during
it --- a version withdrawn from an index is a version somebody's lockfile can no
longer find.