Support the HTTP Spec When Parsing the Accept Header

The method that the codecs package used to match a codec to an entry in an Accept header works for simple cases, but doesn't do much to implement the HTTP spec.  Since the spec is fairly specific about how the entries in an Accept header should be parsed and in which order they should be matched, I started writing a quick update to match the spec.

That "quick update" is now over 500 added lines.  Whoops.

A quick summary of the goals of this commit:

### Implement a method of ordering the preferred Accept header entries based on the HTTP spec

Here's the spec for the Accept header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

My explanation of how I've implemented the spec is in the comments in accept.go, lines 129-149.  I think (read: hope) I implemented everything.

### Allow codecs to support more than one content type

The existing json codec can technically support both application/json and text/json content types.  The xml codec can support application/xml and text/xml.  The codec I've written for my project (which uses the vendor extension) can support application/vnd.radiobox.encapsulated+*.  For these codecs, I've made a new codec interface which implements a matcher, so that the codec can implement the content type matching logic.

### Stay compatible with current code

Some of the code (like the wrapCodecWithContentType function and corresponding wrappedCodec struct) is mainly there to avoid changing function parameters and return values, so that everything stays backward compatible.  In its current state, this code does work with the current stretchr/goweb:master (I ran goweb's tests using this code and everything succeeded) and should work just fine with any codecs written for the code in current stretchr/codecs:master (in case anyone has written custom codecs for their projects - I know I have).

As far as I know, none of this code breaks backward compatibility in any way.  I believe that my most recent commit fixed the only code that wasn't completely backward compatible.

### Avoid slowing things down

The simple case that I mentioned above shouldn't be severely affected by these changes, if I correctly understand how Go works.  I believe that it will be slower, but I don't think the difference will be significant.

Longer accept headers will probably run a bit more slowly, but chances are the old code would return the wrong codec for long accept headers, anyway.