Consider overhauling external/skiboot code and upstreaming

[erichte-ibm]

There are a significant number of changes to the skiboot edk2-compat code that was supposed to be a direct copy of the code from skiboot. This goes against the idea that secvarctl is using the exact same code that firmware uses. While it is far too late to go back and fix deployed machines using the skiboot code, we can at least attempt to amend the inconsistency between the two.

There are a few options of differing levels of work:

1. Do nothing, carry changes in secvarctl as is
2. Reorganize the skiboot/edk2-compat code to function better as a standalone library
3. Shove the skiboot/edk2-compat code into libstb-secvar, and migrate skiboot to use libstb-secvar

---

Option 1

Obviously the easiest solution is to ignore the wild differences between skiboot and secvarctl's versions of the edk2 backend. We can continue to document the changes we make. This is personally least preferable to me, as that leads to a large section of code that we will constantly have to dance around, potentially avoid in static analysis, formatting, etc, BUT we can't largely ignore as we do libstb-secvar, being a separate project.

A sub option here is that secvarctl becomes authoritative, and we move it from external/ to backends/host, and thus stops being considered "external" code. We would then break any consideration of it being the same code as in skiboot, however.

---

Option 2

Most of the changes made to the edk2-compant backend were largely to work around specific skiboot-isms. This option would see separating out some of the code from headers, files, etc and a migration to using the crypto abstractions, so that the files can work without needing anything from skiboot. Then, no changes should need to be carried in secvarctl for the skiboot/edk2-compat.

Ideally, this updated version would then be sent upstream to skiboot, so that the code between the two can finally be consistent, despite being quite a bit late.

---

Option 3

This is probably the most invasive change, but the final option is to complete the original intent of libstb-secvar: have it be a single library that handles secure boot key management for all POWER secure boot platforms. This would see upstream skiboot to change to use libstb-secvar instead (either as a new backend, or just straight up amend the old edk2-compat backend). Then any edk2-compat specific code would be moved to libstb-secvar, and there would only need to be one source of external code.