Currently our R6RS 'import' form automatically transforms an import like
(srfi :n ...) to (srfi srfi-n ...).

This works fine with the SRFIs that ship with Guile and any extra SRFI
modules defined with the verbose name format (srfi srfi-n ...).

However, when one really defines a library named (srfi :n ...), then
'import' fails to find this because it only looks for the verbose name.

Here a transcript showcasing the issue:

--- snip ---
scheme@(guile-user)> (library (srfi :200) (export test) (import (rnrs base)) (define test 'test))
scheme@(srfi :200)> ,m guile-user
scheme@(guile-user)> (import (srfi :200))
While compiling expression:
ERROR: no code for module (srfi srfi-200)
scheme@(guile-user)> ,use (srfi :200)
scheme@(guile-user)> test
$2 = test
scheme@(guile-user)>
--- snip ---

(Use-modules actually finds it, as you see.)

The attached patch makes our R6RS 'library' form automatically transform
a library name like (srfi :n ...) to (srfi srfi-n ...).

Will this leak out to the user in such a way that it breaks conformance
or creates problems?  Is it bad that this time 'use-modules' won't be
able to find (srfi :n ...)?  I don't think it is; users should just use
(srfi :n ...) with 'import' and (srfi srfi-n ...) with 'use-modules'.

Note that it's actually not 'import' itself that does the reverse
transform but a deeper part of the system, and thus for instance the
'environment' form from (rnrs eval) also correctly resolves the module
name (srfi :n ...) to (srfi srfi-n ...).  If there are any "holes" left
where the transform doesn't happen, we should be able to plug those too.

WDYT?