releng/docker/build-init.sh: make it easier to customize kernel versions

[ahesford]

This is an alternative to #675 that refactors some of the update flow:

1. Multiple -u options no longer trigger special behavior. It always makes sense to skip kernel and ZFS upgrades with -u, because we don't have the headers available to rebuild kmods in either case.
2. A singleton update_xbps can be run multiple times without re-fetching the package index or trying to update xbps.
3. A new -k argument allows simple specification of a single kernel series for use in the image:
   • This will trigger the installation of dkms, the kernel package and its headers
   • A default override in config.yaml is created to match the specified series (this is added to the YAML overrides first, so users can explicitly override it again)
4. A new -z argument will trigger a ZFS update iff a kernel series is specified.

I can't really test some of the update logic because this change requires a new container, and that container is necessarily up to date. However, I did test with -k 6.6 and -k 5.10 (leaving 5.10 out of the container image) and have confirmed that the module builds appropriately, a ZFS update will be attempted if -z is provided, and the output images seem to use the specified kernel.

After merging this, I'll build a :development container image that people can use until we tag a new release.

[ahesford]

With this change, I would be comfortable shipping a release image that only contains a single LTS kernel (6.6 at this point, I guess) because it will not be cumbersome (although it will be time consuming) for users to build ZFS on demand for their custom images.