first cut at implementing C3 MRO algorithm works for one good case

See also:

http://en.wikipedia.org/wiki/C3_linearization
http://192.220.96.201/dylan/linearization-oopsla96.html
http://www.python.org/download/releases/2.3/mro/
remove bogus imports, one of which caused build failure

(Eclipse doesn't do Maven scopes, so production code can reference
test code by accident without error in Eclipse, but fails when built
with Maven.)
C3: additional tests, including one demonstrating order disagreement
remove extraneous comment
rewrite C3 to be shorter and clearer

This is one of those algorithms that can be more succinctly expressed
in a language with a functional flavor, but we're stuck with plain
Java here, so imperative, it is.
C3: Object should be last in MRO
pom: deploy to sonatype repositories
improve diagnostics when an inconsisten class hierarchy is encountered
Source >> Format
move C3 into us.bpsm.edn.protocols
Protocols now resolve methods using C3 linearization
Protocols now resolve methods using C3 linearization

Protocols will now use the first implementation that matches according
to a C3 linearization [1] [2] of the inheritance DAG.

[1] http://www.python.org/download/releases/2.3/mro/
[2] http://192.220.96.201/dylan/linearization-oopsla96.html

Note, that C3 will fail on inheritance DAGs with inconsistent
ordering. In Python this is avoided by not allowing such classes to be
defined in the first place. In Java, we have no control over
inconsistencies in the relative ordering of Interfaces implemented by
our super classes, if we haven't written those classes ourselves. I
have not yet observed this in practice, but it can be worked around by
registering implementations for any concrete classes that have such an
inconsistency in their ancestry. Alternatively, the implementation of
Protocol.Builder could be extended to allow an explicit linearization
to be specified for problematic classes or interfaces.

Merge branch 'topic/c3':
  Protocols now resolve methods using C3 linearization
  move C3 into us.bpsm.edn.protocols
  Source >> Format
  improve diagnostics when an inconsisten class hierarchy is encountered
  C3: Object should be last in MRO
  rewrite C3 to be shorter and clearer
  remove extraneous comment
  C3: additional tests, including one demonstrating order disagreement
  remove bogus imports, one of which caused build failure
  first cut at implementing C3 MRO algorithm works for one good case
make Protocol generic; no longer limited to just Function

The domain of a Protocol can now be any time F, not just Function. The
interface Function has been removed.

You can think of the Protocol as a kind of immutable Map keyed by
Class, where lookups are resolved using the C3 learization when an
exact match for a given class can not be found in the map.
simplify Printer using newly generic Protocol

The only "configuration" required by Printer is the Protocol of
Printer.Fn implementations. Accordingly, we've removed Printer.Config
and Printer.Config.Buidler in favor of directly exposing Protocol and
Protocol.Builder.

This may need to change should Printer grow options, but as this
Printer isn't a pretty-printer, I don't anticipate that. A
pretty-printer would be a desirable option, but a design for it has
not cristalized yet.
Merge branch 'topic/simplerprinter'

* topic/simplerprinter:
  simplify Printer using newly generic Protocol
  make Protocol generic; no longer limited to just Function
Named.getPrefix() returns "", not null for unqualified names

This means that callers can always assume that getPrefix will return
a reference to a String and need not perform a null-check. (To
distinguish qualified form unqualified names, the pattern is:
n.getPrefix().length() == 0).

Also, add Javadocs to Named, Symbol, Keyword and Tag.
Provide javadocs for all public APIs; add EdnSyntaxException

 - Add EdnSyntaxException, which the Parser now throws in place of the
   less specific EdnException.