finish implementing ACCEPT specializers

A handy example to do dispatch based on the Accept: header in
HTTP requests.  Includes a tricky method combination which
in addition can set the Content-Type: header of the response.

new protocol function GENERALIZER-EQUAL-HASH-KEY

We need arbitrary generalizer objects, not least so as to have
composable specializer functions (if we want generic functions
which can have more than one extended specializer class, we need
to be sure that our generalizers won't stomp on each other).

But that means that cacheing effective methods depends totally on
interning generalizers, which is a bit lame, unless we ask the
extended specializer implementor to provide a subkey to be used
in the key to the emf cache.  This new protocol function is a hook
for exactly that purpose.

(Minimally update the cons specializer example: it's still bad, in
that it uses symbols as the generalizer for conses, but the protocol
in principle at least doesn't leak now.)

accept-header parsing

INSERT routine to insert (and possibly modify the q of) a node

Parser using cl-ppcre, which will win few prizes for robustness but at
least gets the header as sent by Chromium on my computer right...

improve print-object for accept-tree-node

only display the (unparsed) accept string if we are printing
the root node

beginnings of content-type negotiation specializer

method combination and media-type priority computation.  Still needs
work on the accept header parser

get the protocol more right

Include some generic function arguments for specialization in protocol
functions involving generalizers.  (Otherwise there are some cases where
it's not possible to define methods not in violation of the rules about
specializers applicable to instances of not-standard classes.)

Adjust the CONS-SPECIALIZER example to suit, and include an extra test
case which shows of method-combination as well as the new ability to
have multiple applicable methods with class specializers.

fix one package export

one update -CLASS -> -GENERALIZER

test case!

Include some assertions on the behaviour of WALK

flush the EMF cache in REINITIALIZE-INSTANCE of SPECIALIZABLE-GENERIC-FUNCTION

note a fixme

handle arbitrary method combination

I think it's practically impossible to do on our own, certainly
efficiently: handling the pseudo-lisp that is an effective method is
likely to go wrong.  Piggy-back on SBCL, with
SB-PCL::MAKE-EFFECTIVE-METHOD-FUNCTION and SB-PCL::INVOKE-EMF

package fixup for cons specializers

also note a problem with the current protocol

separate out cons-specializer and walk into their own file

initial commit

Somewhat modified version of specializable.lisp from
http://www.lichteblau.com/git/?p=specializable.git
[ commit eb30d235951c3c1d128811278760f1db36cd336c ]

Lightly modified on a first read-through, mostly cosmetic though with
the innovation of the GENERALIZER concept, as in
COMPUTE-APPLICABLE-METHODS-USING-GENERALIZER and
SPECIALIZER-ACCEPTS-GENERALIZER-P.  Lots of FIXME notes for the things
that weren't trivial.