This PR makes the loader and kernel actually use the new BuddyAllocator for frame allocation. This has a number of benefits:

1. Better support for super/hugepages - The memory mapping routines already try mapping at the largest possible page sizes. This currently is limited however by the alignment (or lack thereof) of physical frames. Both BumpAllocator and BitMapAllocator can only guarantee 4kib alignments and adding support for aligned regions would be difficult, wasteful or both. Since the whole spiel of BuddyAllocator is its support for power-of-two alignments, allocating regions with a specific alignment is trivial. The new NonContiguousFrames implementation even allows for non-contiguous but still well aligned allocations of frames.
2. Better support for non-contiguous physical memory - Physical memory might not always be contiguous, different banks can be wired at different addresses resulting in unusable holes in the address space. This is something we have been trying to handle from the start, but the approach used by BumpAllocator was more than lackluster: With a single offset you simply can't bump-allocate properly from multiple regions. And even with multiple pointers, you end up with wasteful inefficient allocations when requesting large chunks such as for the kernel heap.