The `FileSystemInfo` was accidentally different from the intended C
representation of the type due to extra alignment padding inserted after the
`FileSystemInfoHeader` struct. This wasn't noticeable when constructing with
`FileSystemInfo::new`, so the existing unit test didn't catch it. However,
when constructing with `FileSystemInfo::from_uefi`, the volume label info
would go in the wrong place so the beginning of the name would be cut off.

To fix this, merge all the `Header` types into their parent types. Replace the
`NamedFileProtocolInfo` abstraction with an `InfoInternal` trait that allows
each info type to specify the offset to the name field at the end of the
struct.

Also fixed the size checks for constructing file info types with a storage
buffer so that they take alignment padding into account. For example,
`FileInfo`'s alignment is 8, so the total size of the struct will be a
multiple of 8 and the storage buffer needs to have room for that.

The alignment and name field offset values are currently hardcoded for each
struct. This isn't ideal, but it's not easy to avoid in a zero-cost way
without running afoul of safety rules. It is straightforward to validate the
hardcoded values once a type is constructed though, so the unit tests now do
that (see `validate_layout`).

Initializing of header fields is now done with `ptr::addr_of_mut` in a
closure. Since the buffer is currently an initialized slice (i.e. not
`MaybeUninit`), and the header fields are almost all numeric types where any
bit pattern is valid this is really a bit overzealous, but is specifically
neded for the `read_only` field since only two values are valid for
`bool`. And it will make it simpler in the future if we switch the storage
buffer to use `MaybeUninit` to avoid double initialization.

One more alignment improvement: if the storage buffer is not aligned, an
aligned sub-slice is used (if possible). The docstring for
`FileInfoCreationError::InsufficientStorage` already implied this happened,
now it actually does. With this fix it's possible to run the file-info tests
under Miri for some added confidence in the correctness of all the unsafe
code.

rust-osdev#80

This test should catch the issue described in
rust-osdev#80