assemble_cvd: Support prebuilt android_esp.img in android_efi_loader

[zbw182]

When --android_efi_loader is not explicitly specified on the command line, check for a prebuilt android_esp.img partition in system_image_dir (including system/etc/android_esp.img) before falling back to android_efi_loader.efi.

If android_esp.img is present, copy it directly to the instance ESP image path in BuildOSImage, bypassing host-side ESP generation via esp.cpp. If --android_efi_loader is explicitly passed (e.g. pointing to a standalone GBL .efi binary), preserve the existing dynamic generation behavior.

[Databean]

FYI, it looks like there are some build/test errors.
From build-debian-package-amd64

 ERROR: /mnt/build/base/cvd/cuttlefish/host/libs/config/BUILD.bazel:147:14: Compiling cuttlefish/host/libs/config/data_image.cpp failed: (Exit 1): cc_wrapper.sh failed: error executing CppCompile command (from target //cuttlefish/host/libs/config:data_image) external/toolchains_llvm++llvm+llvm_toolchain/bin/cc_wrapper.sh -U_FORTIFY_SOURCE '--target=x86_64-unknown-linux-gnu' -U_FORTIFY_SOURCE -fstack-protector -fno-omit-frame-pointer -fcolor-diagnostics ... (remaining 166 arguments skipped)
  cuttlefish/host/libs/config/data_image.cpp:28:10: error: module //cuttlefish/host/libs/config:data_image does not directly depend on a module exporting 'absl/strings/match.h', which is part of indirectly-used module abseil-cpp+//absl/strings:strings
     28 | #include "absl/strings/match.h"
        |          ^
  1 error generated.

It's possible to reproduce these locally by running bazel test //... anywhere under the base/cvd directory.

[Databean]

FYI we have the project configured to require linear history / rebases instead of merge commits, but GitHub still shows the "Update branch" option which does the wrong thing by default and creates merge commits.

[dimorinny]

The direction is correct: a build that ships android_esp.img should boot through the EFI loader flow by default, and --android_efi_loader should still let us generate the ESP from a given binary. I'd like to change the shape of the fix, though.

Limitations of the current patch

• --android_efi_loader now carries two meanings, an EFI binary or a prebuilt ESP image, told apart by an .img suffix check in BuildOSImage. Every consumer of android_efi_loader() then depends on a naming convention.
• The prebuilt image is copied into the instance dir on every assemble. esp.img is not resume-preserved, so each run bumps its mtime and --resume rebuilds the composite disk and wipes the overlay. Every other prebuilt partition is referenced in place, and the ESP should be too.
• When both files are present, the fetched android_efi_loader.efi should win over the tree's android_esp.img: it only exists because someone asked for it via --android_efi_loader_build. DefaultPaths currently checks the prebuilt image first.
• The system/etc/android_esp.img probe has no precedent. Every image lookup is a flat <system_image_dir>/<name>.img, which is where cvd fetch puts the file.

Proposed direction

• --android_efi_loader keeps one meaning: an EFI binary to generate the ESP from.
• A new instance config field, android_esp_image, holds the prebuilt image's path. DiskImageFlagsVectorization sets it only when the VMM is crosvm or qemu, boot_flow() is still Android, and <system_image_dir>/android_esp.img exists.
• boot_flow() returns AndroidEfiLoader when either instance config field is non-empty.
• EfiLoaderImage::Create returns the prebuilt path when there is no EFI loader, otherwise the generated esp.img as today. The composite-disk code is untouched.
• BuildOSImage returns early when there is no binary to generate from. No copy, no suffix check.
• esp_image_path() becomes generated_esp_image_path(): it is always <instance>/esp.img, written by assemble_cvd for the EFI loader, ChromeOS, Linux and Fuchsia flows, while android_esp_image() comes from the Android build. The rename makes clear at each call site whether the code produces an image or consumes one.

Resulting precedence: explicit --android_efi_loader=<binary>, then an on-disk android_efi_loader.efi, then the build's android_esp.img, then the legacy flow.