The SRFI should probably say that it is an error to mutate a timespec
after making one with the `timespec` procedure.

Timespecs implemented as cons cells are trivially mutable, but that can
cause interoperability problems with implementations that have timespecs
as opaque objects. We'd have to specify portable `timespec-set-seconds!`
and `timespec-set-nanoseconds!` procedures, and that's hardly worth the
effort as it's just as easy to make a new timespec object. Immutable
values also tend to have less gotchas in general (hashing, aliasing, etc.)