Study other enums in uefi-rs

[HadrienG2]

It is well possible that #48 was just the tip of the iceberg, and that we need to rethink the way we handle enums in FFI. To check if this is the case, we should take a tour of the various enums in uefi-rs and determine if...

• The spec might add new enum variants in the future and expose them to us without us asking for it.
• Implementations are allowed to add new enum variants if they feel so inclined.

If the answer to either of these questions is "yes" or even "I don't know", then the enum must be replaced with an integer newtype as was done for Status.

[HadrienG2]

I took a look around. There are two other C enums in the crate which should not be modeled as Rust enums:

• The ScanCode enum of the Input protocol has a range of values reserved for extensibility, therefore it is designed to allow unexpected variants.
• The ProcessorArch enum of the DebugSupport protocol is also subjected to further extensions. UEFI can be and has been ported to new CPU architectures, most recently RISC-V.

I am able to formulate a rough rationale of why the other enums involved in FFI look safe to me, which I have written down in code as comments (since that information is critical to the type-safety of uefi-rs, it seems best to have it in the code). A PR will follow shortly once I have sorted out the two issues above (most likely by generalizing the macromancy that I have introduced for Status).