binding a set of ServableResource classes

also renamed the binder helper to more accurately reflect the purpose
fixing an order problem with a test

silly me, unhooking a latch then flipping a flag.  amateur hour!

also making the timing a little more realistic. 3000 seconds might have
been a little long to let it sit
iterating! on a way to identify ServableResource paths

but i think just a Pattern isn't going to do it, there will need to be a
class that implements some interface
renaming URIMatch#baseName to #path

for clarity.  baseName was a relic of an old, old version
clarifying rules about URI matching

including some new tests! and comments! OH MY
using URIMatch to find routes, so SHAs are handled uniformly

this is step one.  step two is to make extension handling part of the
trie structure. the plan is to refactor SeparatorNode logic into a base
class and make a new subclass that essentially acts the same, but with
special rules - only one per path through the trie, and it disallows
SeparatorNodes to follow it
servable resource configuration

need to bind up quite a few pieces of info to correctly serve a
resource.  for now, we need a friendly name, and a processing class that
can handle firing it off to the http world

also i am sweating like i have a terrorist cousin.
adding a helper to expose servable info

this is the bridge to allow users to control how to route incoming
requests to particular resources.  it's also the path to killing off the
servables structure.  need to work out some details, like route
contribution (word) and the actual connection of the routes but this is
pretty much the design
actually, we don't want to pull classes here

it makes a lot more sense to just get the server out, right? it can
inject whatever it needs, which is stuff to bridge into the resource
system, most likely. whatevs
one must test one's classes

most of the test just comes from Servable, because that was the home of
the "standard" RequestProcessor implementation, most of which now lives
in SimpleResourceServer
errant sysouts
removing a comment

it no longer applies
java8ifying, + comments
comments
experimenting with resource routing

actually all routing.  need to understand how i want this stuff to hook
up - hewing as closely as possible to existing ideas but also keeping in
mind the strengths of this system
errant sysout
splitting route configuration into a separate file

as would be a best practice in the real world, since globalizing the
routing module is the easiest way to use it

also there are some sketches in there.  comments really