Fix fiddly build issues caused by references to quicklisp symbols

[mtstickney]

This PR fixes some strange issues caused by ASDF caching and the way quicklisp symbols are used. At present, with a fairly common build setup you wind up having to load the library, delete the fasls from the ASDF cache, and finish the rest of your build, at which point builds will succeed until the library is updated. Commit message has more details:

The reader conditional for using quicklisp code only does half the job. You will still get unpleasant build errors with the following common scenario:

1. The user loads this library, once, with quicklisp. The reader condition selects the quicklisp loader code.
2. ASDF caches a fasl file for this code, which uses the quicklisp functions.
3. The user loads this library again, without quicklisp.
4. ASDF loads the cached fasl, which refers to symbols in packages that don't exist in the current image, badness ensues.

This change avoids all read-time references to symbols in quicklisp by looking up the symbols in question at run time. The symbol lookups go out of their way to give good error messages if a symbol can't be found, since FUNCALL-ing NIL doesn't tell you anything very helpful. The error type is checked dynamically by using a HANDLER-BIND that traps every condition -- conditions of other types simply go unhandled, and are propagated normally.

The reader conditional has been replaced by a run-time features check, so ASDF/quicklisp will be used based on what's present at the time the system is loaded, and not what was available the first time this library was loaded.

[coveralls]

Coverage decreased (-2.9%) to 86.324% when pulling 6e2c315b3276726b3a48a4592931bbb44fc646e6 on mtstickney:quicklisp_symbol_usage into 2c1c0df583f4b7cc9aba1d97cf9d1131a0fa0096 on fukamachi:master.

[fukamachi]

Thanks!