preinstall: Add checks for PCR4

This adds checks some checks for PCR4.

The caller supplies a context.Context to which an EFI variable backend
is attached, a internal_efi.HostEnvironment implementation, a TCG log, a
PCR digest algorithm (the optimum for this is computed earlier by
another function that does a more general check of the TCG log) and a
list of boot images related to the current boot.

First of all, in the pre-OS environment, it checks that the log only
contains either a single EV_OMIT_BOOT_DEVICE_EVENTS event or a single
EV_EFI_ACTION "Calling EFI Application from Boot Option" event (after
which, it expects to see the EV_SEPARATOR event). It also permits
EV_EFI_BOOT_SERVICES_APPLICATION events in the pre-OS environment if the
BootOptionSupport EFI variable indicates that system preparation
applications are supported, although these must be before the previously
mentioned EV_EFI_ACTION event. The profile generating code in
efi/fw_load_handler.go copies these pre-OS events (including sysprep
applications to the final policy).

Note that firmware that implements v1.06 of the TCG PC-Client PFP spec
implements another EV_EFI_ACTION event that indicates the number of the
Boot option that the load occurred from - this code will need to include
support for that quite soon. There is a corresponding github issue for
this (canonical#308).

Before processing the OS-present part of the log, it reads the
BootCurrent EFI variable and matches this to a EFI_LOAD_OPTION from the
TCG log - it uses the log as load options can be updated at runtime and
might be out of date when this code runs.

When processing the initial part of the OS-present section of the log,
it expects to find the EV_EFI_BOOT_SERVICES_APPLICATION for the initial
boot loader, and it expects the path of this to match the previously
discovered load option - note that it doesn't expect a complete match.
See how path matching works in efi.DevicePath.Matches. Any other event
type at this stage is rejected as an error, as it would result in an invalid
policy being generated by the code in efi/fw_load_handler.go. If the first
EV_EFI_BOOT_SERVICES_APPLICATION event is not the initial boot loader, it
checks to see if it is part of Absolute, in which case it skips it and
looks for the next event. Note that Absolute will be copied to the computed
policy if it is present by efi/fw_load_handler.go, altohugh it's
recommended that this is disabled instead. The next event must be the
initial boot loader, matched to the EFI_LOAD_OPTION that the BootCurrent
EFI variable points to, else an error is returned. It verifies that the
digest in the log matches the Authenticode digest of the first boot file
supplied to the function.

It then continues to process EV_EFI_BOOT_SERVICE_APPLICATION events in
the log (permitting, but ignoring other event types - it's expected that
if other OS boot code uses other event types in the log, the policy
generation code for that OS component in the secboot efi package takes
this into account). For each launch event (EV_EFI_BOOT_SERVICES_APPLICATION),
it verifies that the digest in the log matches the Authenticode digest of
the next boot file supplied. Note that it is not mandatory to verify every
one of these events, but the function does require that the digests of
at least one EV_EFI_BOOT_SERVICES_APPLICATION event other than the IBL is
verified. This ensures that if the IBL loads the SBL outside of the LoadImage
service (ie, how shim loads grub), that the EFI_TCG2_PROTOCOL interface is
properly supported by the firmware to allow the IBL (ie, shim) to properly
measure the Authenticode digest of the SBL (ie, grub). This isn't a test
against OS components, which is is now what these tests are for - it's a
test against firmware behaviour and firmware features.

On success, the function will return a set of flags indicating whether
system preparation applications were detected to be running, whether
Absolute was detected to be running, or whether it wasn't able to verify
all EV_EFI_BOOT_SERVICES_APPLICATION event digests because not all paths
to every component for the current boot were supplied. What happens with
these flags will be customizable with flags supplied to the higher level
RunChecks API.