Add Secure Boot support through shim_lock protocol

[BjornRuytenberg]

There are several potential avenues through which we could support Secure Boot-enabled systems.

1. We submit kdmap-patcher for UEFI signing. kdmap-patcher becomes a first-stage bootloader, and chainloads the respective OS loader.
2. We adapt UEFI shim loader, and request a review for signing our adaptation. kdmap-patcher becomes a first-stage bootloader, and chainloads the respective OS loader.
3. We incorporate support for UEFI shim loader's shim_lock protocol, and act as a second-stage bootloader, before chainloading any subsequent OS loaders. This issue explores this scenario.

Shim offers an API for boot loaders to verify future programs for execution, such as GRUB. kdmap-patcher could fit between shim and GRUB for the purpose of fixing up some parts of the firmware before handing over control to the OS. Without Secure Boot, shim is loaded, our UEFI binary loads, and then we load GRUB which in turn loads Linux. In its current state, with Secure Boot enabled and self-signing our binary [1], shim is loaded, our program is loaded, but then it is unable to chainload GRUB. The code paths are identical for loading, we only get/use the shim_lock protocol if we detect Secure Boot is enabled [2]. Patches for Xen [3][4] and GRUB [5], as well as FreeBSD's approach [6], appear to contain some useful hints. We've posted an issue with Shim [7].

[1] Similar to https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface/Secure_Boot#Signing_EFI_binaries
[2] https://github.com/BjornRuytenberg/kdmap-patcher/blob/sb-efi-shim-testing/src/boot.c#L91
[3] https://lists.xen.org/archives/html/xen-devel/2017-07/msg00982.html
[4] https://lists.xen.org/archives/html/xen-devel/2017-07/msg00981.html
[5] rhboot/grub2@878398c
[6] https://wiki.freebsd.org/SecureBoot
[7] rhboot/shim#217