fallback.efi as a separate binary creates a pile of issues:

• with tpm enabled, the fallback path has to reboot, so that the new boot option doesn't have fallback in its history of PCR[7] values
• that means we need to detect boot loops
• if the reason fallback has been run is that variables are defective, as is fairly often the case, detecting boot loops won't work
• people get confused about when and where to put it on various kinds of media

If fallback is a function rather than a separate executable, things are better:

• we can go back to just directly launching whatever boot entry we select
• we no longer have to deal with fallback in the path mangling in set_second_stage()
• fallback still succeeds when boot variables are horribly broken
• fallback no longer needs to exist in the make files
• it doesn't need to be on the media
• we don't need to worry about how it's signed/hashed/etc.

There are a things we need to ensure when doing this as well:

• must have a well defined and documented way of deploying shim on removable media/recovery media/cloud that doesn't invoke fallback. I'm thinking the right answer here is probably the presence of a second stage bootloader in the current working directory.

(Previously discussed here: #418 (comment) )