Make RGBLINK usable in a C toolchain

More needs to be done for RGBLINK to become a viable C toolchain linker, in order of importance:

- [x] Linker script must be able to specify floating sections (SDCC "floating" areas do not convey any "type" info, so the linker script must specify whether they are ROM0, ROMX, etc. but that shouldn't force their location.)
- This is half-supported; we have floating section addresses within banks, but we also want floating banks common to all their subsequent sections (i.e. #244 but in linker scripts)
- [x] Linker script must be able to specify "optional" sections (i.e. reference sections but not error out if they don't exist)
- [ ] `.cdb` support
- [ ] Document how the SDCC and RGBDS worlds interact
- [ ] `.lib` support (`ar` archives, and lazily linking `.o`s from those)
- [ ] `.noi` support (essentially `.sym` with a different format)

These smaller points cover TODO comments in the source code, marking partial support for, or incomplete understanding of, something checked off above:

- In src/link/sdas_obj.cpp:
- [ ] Handle `;!FILE [...]` on the first line
- [ ] Hard error if the rest of a `Ref` line is not zero
- [ ] Possibly check other flags for relocatable/PC-relative byte patches
- In test/link/sdcc/good/script.link:
- [ ] Investigate the `"_GSINIT"` ROM0 section ("reportedly internal to the crt0")
- [ ] Identify what the `"_DABS (ABS)"` WRAM0 section is

Start by reading the TODOs in src/link/sdas_obj.cpp and the SDCC linker fixture at test/link/sdcc/good/script.link. Map each unchecked item to the existing linker behavior, then verify that the requested .cdb, .lib, and .noi support, documentation, and SDCC-specific cases are covered before considering the issue complete.

Written by the indexing model from the issue text.