Merge AndroidEfiLoaderCompositeDiskConfig with AndroidCompositeDiskConfig

[Databean]

We now have the ImageFile mechanism where partitions can be supplied dynamically. Since the main contribution of AndroidEfiLoaderCompositeDiskConfig, this can go through the ImageFile logic instead.

Tested with a build fetched using --android_efi_loader_build=aosp_uefi-gbl-mainline/gbl_efi_dist_and_test.

Bug: b/491903055

[cjreynol]

I saw you came up with a test case, but consider checking with Dmitrii or Ram if there are any other cases to check? I am just ignorant to how disruptive a breakage here might be and am defaulting towards greater caution.

[Databean]

FYI @dimorinny

[Databean]

Looks like this "happens to work" in an unintuitive way. There's a comment in the code from before this CL saying

Cuttlefish uboot EFI bootflow by default looks at the first partition for EFI application. Thus we put "android_esp" at the beginning.

As written here, the partitions are put in a std::map keyed by partition name, and android_esp happens to be first because std::map uses a tree sorted on keys to store entries. I tried renaming the partition so it would be sorted later, and confirmed that u-boot will not find it when it is later in the GPT.

[cjreynol]

Based on the latest comment about this not necessarily working except in certain cases.

[Databean]

The "insert at the beginning" logic is now more explicit.

[dimorinny]

Thanks Cody, it looks good to me!