Move to non-enum Status for type safety reasons

[HadrienG2]

As discussed in #48 and #44 before that, it is not safe to use a Rust enum for UEFI status codes due to their open-ended nature. For this reason, this PR proposes to use a newtype of usize and a bunch of constants instead.

A small amount of macromancy is used to reduce the noise and repetition that is inherent to this approach and keep the code readable.

Fixes #48.

[GabrielMajeri]

Instead of making them constaints in the status module, what if we just made them associated constants of the Status type?

pub struct Status ...;

impl Status {
    pub const SOME_ERROR: Self = 0;
}

This should greatly reduce the number of changes required.

[HadrienG2]

@GabrielMajeri Cool, did not now you could use that outside of the trait system! Implemented. Now there's only the minor warning question to be resolved and we should be all set.

[GabrielMajeri]

(CI failed due to rustfmt)

[HadrienG2]

In principle, one could build a macro which would reproduce the full enum feeling by using recursion to generate a sequence of numbers from a starting point. However...

• I'm not sure what the impact of all that recursion would be on compile times.
• That would add a fair bit of complexity which I would be relucant to add just for our status codes. I would feel less uneasy if we had other C-like enums to deal with in a similar way (maybe we do!), or if this were available as part of a more general FFI helper crate.

[GabrielMajeri]

@HadrienG2 I don't expect to see a lot of status codes being added to the spec anytime soon. The current solution is good.