efi/libstub: Look for initrd LoadFile2 protocol on image handle

The use of a global singleton device path for describing the initrd to
be loaded by the kernel implies that only a single handle can exist that
carries the initrd LoadFile2 protocol implementation.

This avoids the need on the part of the EFI stub to reason about which
initrd is the preferred one when several are being provided - we already
have initrd loading via the setup header on x86 and via DT on other
architectures, in addition to the initrd= command line option, and so
having a single loader provided initrd that supersedes all of them was
deemed preferable over having multiple sources.

However, this means that intermediate loader stages cannot simply
install the LoadFile2 initrd device path, and will need to check for
failures and deal with them. It also means that such stages will have to
reason about whether or not the subsequent stage being loaded is the
final one, or whether it may attempt to install the initrd device path
itself.

We can solve this by associating the initrd LoadFile2 protocol with the
loaded image instead of with a global singleton device path. That way,
each stage can associate any initrd it provides with the image that it
is loading.

Tested-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>