[zx] Magenta -> Zircon

The Great Renaming is here!

Change-Id: I3229bdeb2a3d0e40fb4db6fec8ca7d971fbffb94

[fs][devmgr] Add VMO kernel files to bootfs

Add a mechanism for the kernel to pass (potentially large) data files to
devmgr via a VMO handle, with handle_info of type PA_VMO_KERNEL_FILE.
devmgr will add any such VMO as a file in bootfs. This is meant for
debugging and testing during early boot.

Change-Id: I3e79d75274d80c78e7bf4cac33d924aaf74e308d

[utest][vdso-variant] Enable the test for opening vdso files writable

https://fuchsia-review.googlesource.com/c/32126/ fixed the VFS issue
that required disabling this test.

Change-Id: If6f450da8a295e0148b527a443af3c45a4353e7e

[kernel][vdso][userboot][devmgr] Machinery for variant vDSOs

This provides machinery to implement multiple variants of the vDSO.
Each variant can blacklist some of the functions so their symbols
are not visible to dynamic linking and their code gets blacked out
so there's no secret jump targets to use.

Because all the variants are just subsets of the full-featured vDSO,
all the code addresses still match across all variants and the
syscall entry enforcement machinery doesn't need to care which
variant is being used.

All the available vDSO VMOs are attached at /boot/vdso/<name>, where
<name> is "full" for the primary vDSO and other names will be used
for variants. Currently, only some test variants are implemented.

Each variant can blacklist one or more category of syscalls. A
category is any attribute name used in syscalls.sysgen. A new
variant is added by adding an element to the VDso::Variant enum and
adding a case for that to VDso::CreateVariant that sets the name
and calls blacklist_<category>_syscalls for each category to be
blacklisted in that variant.

Change-Id: I32e5ee658a903365fff234e22738f7127622ed33