WIP: Asset groups

This is an initial implementation of #52 (closed). It's incomplete, even in terms of the subset of features it's meant to satisfy (support for asset variants is missing).

Opening a merge request to keep track of the work, however I think I'm going to delay this further.

It has occurred to me that there is a less large and intrusive way of handling the one concrete feature this would provide at the moment, and I'm still not sure about the benefits of using this (though #168 might make it more usable).

For now though, it has occurred to me that to handle rebuilds of packages such as project-atlas (using the atlas generators), which should be rebuilt whenever any of the textures used for the atlases change (ensuring that the textures exist would still be useful, but is less necessary since the build will just fail if they don't with a relatively informative usage message), we could do the asset tracking without having to register groups by just providing a function that allows you to add to a list of assets that should have their hashes stored in the VDB and trigger a rebuild if they don't match the current versions of the assets in the VFS. Better still we could have it support glob patterns, and make rebuilds also occur if new files match the pattern. E.g. for omwllf, it could track *.esp, *.omwaddon, etc. and rebuild whenever any plugin either changes in content, is added, or is removed. Then we could remove the old rebuild on plugin change behaviour (which is a little over-enthusiastic).

That being said, if this is to be supported eventually, we will need a manifest format capable of storing file contents, so what I think should probably be done is to start using the new manifest format (minus archive contents), given that a dictionary-based manifest is much more extendable than the current line-based format.