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

• renameentry_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 theRewriting History guide for help.
• Update the changelog (if necessary)