Add a library crate to the repo for downloading/caching prebuilts

[nicholasbishop]

As mentioned in #37 (comment), I'd like to add a library crate here, essentially an upgrade to https://crates.io/crates/ovmf-prebuilt to make it easy to get the new prebuilts.

Filing an issue here to lay out a quick plan:

1. Make the repo a workspace so we can have multiple packages. Initially this will just be one package, build-edk2, containing the code that's currently in src/. build-edk2 will not be published.
2. Add an ovmf-prebuilt package to the workspace. This can start at version 0.2.0 to supersede the currently-published versions.
3. Implement functionality in ovmf-prebuilt similar to what we have in uefi-rs: https://github.com/rust-osdev/uefi-rs/blob/ccdfb66cd073442e3dc08412a7c18369d906aff7/xtask/src/qemu.rs#L95. This differs from the previous approach of putting the binaries directly in the crates.io release. I couldn't find any specific policy about uploading prebuilts on crates.io, but this discussion makes it sound at least discouraged.

[phil-opp]

Sounds good to me overall!

This differs from the previous approach of putting the binaries directly in the crates.io release. I couldn't find any specific policy about uploading prebuilts on crates.io, but this discussion makes it sound at least discouraged.

Yeah, I wasn't sure about that either. I'm fine with trying a GitHub download instead, but that approach has drawbacks too (network connection required, no longer self-contained, forking more difficult, etc).

Implement functionality in ovmf-prebuilt similar to what we have in uefi-rs: https://github.com/rust-osdev/uefi-rs/blob/ccdfb66cd073442e3dc08412a7c18369d906aff7/xtask/src/qemu.rs#L95.

For the crate, we could do the downloading in a build script and place the artifacts in OUT_DIR. Then we don't need to do any hash checks as the build script is only run on the first compile.

[nicholasbishop]

https://crates.io/crates/ovmf-prebuilt/0.2.1