This error variant was used to encode that no error actually happened,
which does not make much sense conceptually. What made this worse is
that is contained a FcExitCode, which is itself just a fake Result<(),
non-zero-exit code>. This means it was possible to get Firecracker to
exit with status "error, but not actually error, but actually there is
an error after all", or: "Firecracker exited with an error:
Microvm stopped without an error: GenericError".

The underlying problem here is the fact that we are using `FcExitCode`
as an error variant for `Result`. Since `FcExitCode::Ok` exists,
`FcExitCode` is a kind of `Result` itself, meaning we are dealing with
`Result<_, Result<_, _>>` as a type, which has no well-defined
interpretation.

Signed-off-by: Patrick Roy <roypat@amazon.co.uk>

Using FcExitCode as an error type is undesirable, as it allows us to
construct Err(FcExitCode::Ok), e.g. an object that says "error:
everything's okay!". This is confusing and has caused problems in
different contexts before, so replace FcExitCode with a proper error
type here.

Signed-off-by: Patrick Roy <roypat@amazon.co.uk>

Previously, when a VM exited, we looked for the first vcpu that reported
an exit status, and then indiscriminately reported that back. However,
it is possible to one vcpu to exit successfully while another exits with
an error, and this could lead us to report "Firecracker Exited
Successfully" even though it did not.

Now, we explicitly look for the status code of all vcpus. If any of them
report an error, this takes precedence over non-error status codes.

Signed-off-by: Patrick Roy <roypat@amazon.co.uk>