Split Gambit's extensions into separate pseudo-modules

[per-gron]

Gambit implements R5RS. Moreover, it extends it, with for instance homogenous numeric vectors, records, dynamic scope (parameter objects, aka "fluid" variables), powerful I/O and ports, exception handling, APIs for accessing the host environment, threads, a C FFI and more.

It might be nice to categorize some of this stuff into separate built-in pseudo modules. For instance, requiring users to do something like (import (std threads)) to use threads, or (import (std srfi/39)) to use parameter object procedures.

Some of these things are implementations of SRFIs (for instance parameter objects) while some of them are not and probably shouldn't be (like the C FFI). Some of them are smaller extensions that make sense to place together with existing, related, functionality (vector-copy should be together with the other vector manipulation functions) while some of them are logically separate, like threading.

I'm not thinking of splitting Gambit into tiny pieces so that you need to import lots of tiny stuff. It just seems logical to split out at least the SRFI stuff. I'm not sure that this is a desirable thing to do at all, but I add it as a feature request here just to indicate that this idea is on the radar.

Implementation wise, this isn't difficult at all. The machinery is already there. It would require continuous work to keep up with Gambit as more procedures are added, right now it's done automatically by reading ~~lib/gambit#.scm. The main work that needs to be done is to categorize all Gambit's procedures and decide which ones should be there by default and which ones that should be in separate modules, and if so, which.

But I would strongly vote against doing any of this before it is a syntax error to have unbound variables in modules. Doing this would introducde significant backwards incompatibility, but that would at least show code that breaks.