Make RGBLINK usable in a C toolchain

[ISSOtm]

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

• 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. Add a way to force two sections to be in the same bank #244 but in linker scripts)
• 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 .os from those)
• .noi support (essentially .sym with a different format)

[Rangi42]

Blocked by #1258

[Rangi42]

The goal is to implement floating and optional linker script sections for 0.7.0. (See the discussion starting in #rgbds-dev.)

[ISSOtm]

I think we should have both ROMX FLOATING for "floating bank", and ROMX 42 \n FLOATING for "floating address" (mirroring ORG's usage), so that the two feature sets are orthogonal. (I don't like just ROMX making the bank floating, I think it's too easy for it to be a mistake, especially for auto-generated scripts.)

[ISSOtm]

The semantics of ROMX FLOATING actually kind of suck, because then all assignments in the section have to start somewhere. More useful semantics would be obtained by instead placing all "fully constrained" sections from the object files, processing the linker script (and FLOATING sections would be immediately placed wherever available), and then running the full placement routine with everything remaining.

But that's a lot more work, so I'd like to defer the implementation of that to a later version (probably in the Rust port anyway lolololo) and "only" implement FLOATING addresses. That would significantly hinder integrations, but I think it should enable some early but nonetheless valuable experimentation.