kern: allow kern_shm_open2 of an anonymous preconstructed shmfd

[kevans]

Summary

The motivation here is for future changes to the coredump code to be able to
build up a coredump into a shmfd instead of a vnode, which then gets tapped
out to userland via a character device. This also opens up the possibility
that it's useful for the kernel to be able to construct a shmfd and pass it
out to a process that shouldn't need to write to it.

[kib]

Still want to see any caller with shmfd != NULL

[kevans]

In D51336#1172500, @kib wrote:

Still want to see any caller with shmfd != NULL

I do this here, specifically: https://git.kevans.dev/kevans/ucored/src/branch/wip/kmod/kmod/coredump_ucored.c#L117

That shmfd is populated down in the coredumper it installs. I suspect I'm going to play with the interface a little bit as far as how userspace actually receives these new fds, but I don't anticipate much change in the parts relevant to this review. My current plan is to try and get the interfaces I need into 15.0 (this stack of 3 is sufficient), then iterate on it a bit in ports. I think ucored(8) and the associated kmod would eventually be a good addition to consider for base as it'll add significant flexibility to what one can do with these things (to include piping them to some command, which is native functionality to a Linux kernel but more complicated than I care to implement).