Kernel: Remove i686 Support

[supercomputer7]

trafficstars

As per discussion in the Discord about this today, it was decided finally by @awesomekling that i686 should be removed. The decision was taken after it was proven that i686 is a niche feature and causing more harm than good, so we all should move on to use x86-64. The conclusion was that 32 bit computing is quite limiting (because of small virtual memory space being available) so we should only support 64 bit CPU architectures, hence we should support x86-64 for now (and in the future, aarch64 too).

This is a list of what is needed to be done before dropping i686 support for good:

• [ ] Fix UserspaceEmulator to support 64 bit opcodes
• [ ] LibDebug not understanding DWARF 5 location ranges (mentioned by @ADKaster on the discussion)
• [ ] Disassembly support for x86-64 for proper debugging (mentioned by @BertalanD on the discussion)

We need to revive #13300 and merge #15441 first. Then we probably need to ensure that UserspaceEmulator behaves correctly under x86-64 and LibDebug is usable too. Then we could probably move on to remove all mentioned i686 options around in the Kernel and userland as well as in the build system, Lagom and in the CI scripts.

cc @awesomekling @AtkinsSJ @BertalanD @timschumi @sin-ack @Hendiadyoin1 @ADKaster

[timschumi]

#11592 potentially comes into play as well (not necessarily the Clang part, but...).

[nico]

In case anyone else goes looking for it: The discussion in Discord mentioned above is at https://discord.com/channels/830522505605283862/830525093905170492/1026208632242712677 and above.

[Mammux]

Some documentation has to be updated, like https://github.com/SerenityOS/serenity/blob/master/Documentation/BuildInstructions.md.

[kleinesfilmroellchen]

Other to-be-updated documentation includes the bare metal instructions

[supercomputer7]

We are getting very close to merge #15467. Once that happens then a bunch of fixes are possible:

• We should no longer restrain the kernel to allocate up to 800 MB of virtual memory. We should be able to allow tmpfs to allocate much more virtual memory too!
• We could optimize the kernel to create a big flat window in the end of virtual memory space to map all physical address space. This means that all MMIO being done could be done via that window instead of allocating a virtual memory region per driver.
• We should be able to finally use more RAM than 4GB, and to do that we need to patch up some code in the memory manager to be able to allocate above that barrier and to fox other issues with the way we allocate memory during enumerating memory.