memory map: improvements to fight pitfalls (MemoryMap now owns the memory)

[phip1611]

Follow-up of #1174 that improves the MemoryMap abstraction.

• rename entry_size -> desc_size
• better documentation
• unify usage of common constructor with sane assertions
• removed lifetime/reference, type now owns the memory (which makes much more sense IMHO)

This is an attempt to simplify the overall complex handling of obtaining the UEFI memory
map. We have the following pre-requisites and use-cases all to keep in mind when
designing the functions and associated helper types:

• the memory map itself needs memory; typically on the UEFI heap
• acquiring that memory and storing the memory map inside it are two distinct steps
• the memory map is not just a slice of [MemoryDescriptor] (desc_size is bigger than
  size_of)
• the required map size can be obtained by a call to a boot service function
• the needed memory might change due to hidden or asynchronous allocations
  between the allocation of a buffer and storing the memory map inside it
• when boot services are excited, best practise has shown (looking at linux code)
  that one should use the same buffer (with some extra capacity) and call
  exit_boot_services with that buffer at most two times in a loop

This makes it hard to come up with an ergonomic solution such as using a Box
or any other high-level Rust type.

The main simplification of my design is that the MemoryMap type now doesn't
has a reference to memory anymore but actually owns it. This also models the
real world use case where one typically obtains the memory map once when
boot services are exited. A &'static [u8] on the MemoryMap just creates more
confusion that it brings any benefit.

The MemoryMap now knows whether boot services are still active and frees
that memory, or it doesn't if the boot services are exited. This means
less fiddling with life-times and less cognitive overhead when

• reading the code
• calling BootService::memory_map independently of exit_boot_services

Checklist

• Sensible git history (for example, squash "typo" or "fix" commits). See the Rewriting History guide for help.
• Update the changelog (if necessary)

[phip1611]

This took me a while - it was much more complicated than anticipated. It is hard to come up with a nice and rusty solution due to the many conditions and limitations mentioned above (and in the commit messages). I think this is a clear improvement as we could get rid of the lifetime/slice in Memory Type.

[nicholasbishop]

This should be unsafe, but I'm not sure if it's needed at all; can we just fold it into new?

[phip1611]

It is needed. It is the common constructor for the unit test constructor and the runtime constructor.

[phip1611]

Marked as as unsafe.

[nicholasbishop]

I agree, changing MemoryMap to own the memory should make for a clearer API.

[phip1611]

Ready for the next review round. I know this is complex and hard to review, but I think it is definetely a step forward and an improvement. Let me know what you think @nicholasbishop - I hope I could address all open questions.

I recommend to review this commit by commit.