boot: separate BIOS from UEFI

boot/bios/ now holds the MBR, the El Torito stub and the real-mode stage
2; boot/uefi/ is empty and documented.

Separate directories rather than #ifdefs, because the two share almost
nothing. A BIOS loader lives in 16-bit real mode, reaches the firmware
through software interrupts, and walks itself up into long mode. A UEFI
loader is a 64-bit PE that the firmware has already placed in long mode
with paging on, calling services through a table of function pointers.
What they do share is the hand-off contract, which boot/README.md now
writes down: ELF segments placed, long mode, a 24-byte-entry memory map
at E820_MAP_ADDR, framebuffer geometry at VBE_INFO_ADDR.

That contract is the point of documenting it now. UEFI's GetMemoryMap
returns EFI_MEMORY_DESCRIPTORs, and the right move is to translate them
into the entries kernel/arch/x86_64/e820.c already parses rather than
teach the kernel a second format.

Build output paths under $(BUILD)/boot are unchanged; only sources moved.

boot/bios/cdboot.S

@@ -0,0 +1,48 @@
+# Stage 1 for optical media -- the El Torito "no emulation" boot sector.
+#
+# This exists because bootasm.S cannot boot a CD. It loads stage 2 by talking
+# straight to the primary IDE controller's ATA registers, and a CD is not an
+# ATA disk: it answers to the ATAPI packet interface instead, and under
+# El Torito it may not even be the drive at 0x1F0. Rather than teach a
+# 512-byte sector two protocols, optical media get their own first stage.
+#
+# It has almost nothing to do, because El Torito's "load segment / sector
+# count" fields do the reading for us: tools/mkiso.sh asks for
+# 1 + STAGE2_SECTORS virtual sectors at 0x7C00, so by the time this runs the
+# BIOS has already placed stage 2 at 0x7E00 -- exactly where bootasm.S would
+# have put it. The only real work is recording *which* medium we came from,
+# since stage2main.c has to read the kernel back with the matching protocol.
+#
+# The flag goes next to the verbose-boot flag, one byte past it, for the same
+# reason that one sits where it does: it is clear of the 256-byte VBE mode
+# info block at 0x30000 that stage2.S fills in a moment from now.
+
+#define STAGE2_ADDR            0x7E00
+#define BOOT_MEDIA_FLAG_SEG    0x3000
+#define BOOT_MEDIA_FLAG_OFF    0x101
+#define BOOT_MEDIA_CD          1
+
+.code16
+.global start
+start:
+  cli
+  xorw    %ax, %ax
+  movw    %ax, %ds
+  movw    %ax, %ss
+  movw    $0x7c00, %sp
+
+  # "You were booted from a CD." stage2main.c reads this to decide between
+  # ATA and ATAPI; without it the loader would read the kernel off whatever
+  # happens to be sitting at 0x1F0, which on a CD boot is usually nothing.
+  movw    $BOOT_MEDIA_FLAG_SEG, %ax
+  movw    %ax, %es
+  movw    $BOOT_MEDIA_FLAG_OFF, %di
+  movb    $BOOT_MEDIA_CD, %al
+  movb    %al, %es:(%di)
+
+  # stage2.S expects zeroed segments and an inherited stack, same as it gets
+  # from bootasm.S.
+  xorw    %ax, %ax
+  movw    %ax, %es
+
+  ljmp    $0, $STAGE2_ADDR