Moved memory-management crates into kernel/memory

[NathanRoyer]

This moves the following crates:

• block_allocator
• entryflags_x86_64
• frame_allocator
• memory_initialization
• memory_structs
• memory_x86_64
• page_allocator
• page_table_entry

into theseus/kernel/memory, similarly to what was done to ACPI-related crates.

With this PR, there are less crates in theseus/kernel/.

Additionally, most non-memory crates now use re-exports from the memory supercrate, which makes it easier to know what re-exports other crates actually depend on, from these crates. There is one exception: I left the direct import from nano_core to memory/memory_initialization because removing that dependency looks more difficult than what I did in this PR; removing that dependency can have its own PR, imo.

[NathanRoyer]

Note: all file modifications with this icon:

are files that were simply moved without internal modification. I hope this simplifies your review.

[kevinaboos]

Thanks, this looks pretty good. Also a step forwards in the right direction re: #51.

Currently there is a CI build error, but I'm going to wait until all the current memory subsystem changes are merged to address this anyway.

[kevinaboos]

alrighty, all the memory subsystem changes have been merged in now, so we can accept this PR whenever you're able to merge in the latest changes from theseus_main and address the failing CI checks. 👍

[kevinaboos]

Some top-level comments:

• bootloader_modules shouldn't be part of memory; this is debatable, but I think we'll end up moving it into a bootloader-related directory after UEFI support is added.
• more crates can be moved into memory/ (we could do this later too). Some of these are already part of this changeset but you didn't include them in the PR description (pls update the description accordingly)
  • heap
  • multiple_heaps
  • mapper_spillful
  • all the 3 slabmalloc* crates
  • stack

In general, we want to keep dependencies to a bare minimum for each given crate. It makes compilation way faster, and most importantly, we want to keep the scope and file size of the compiled nano_core to a minimum. Specific actions for this are:

• avoid changing a crate to depend on the huge memory crate unless it already depends on memory
  • for example bootloader_modules only needs one tiny type from memory_structs, it doesn't need all of the memory crate
  • This is mostly important for crates that operate early on in the OS init procedure
• avoid adding every sub-crate within the memory/ crate as a dependency/re-export in the top-level memory crate (this differs from how acpi is organized)
  • We can do this for some select crates (as we already to with the allocators, etc) but it's not necessary to apply it to all sub-crates