Add support for passing a Proc to routes

[glittershark]

Add support for passing a Proc to routes instead of a regular
expression for matching - this proc will then be called with the message
in the context of the handler object and should return a boolean
indicating whether the route matches or not.

This allows for dynamically defined routing, plus support for
configuring things like command names and prefixes, which is useful as
plugin configuration is only available on a handler instance, not the
singleton.

Probably addresses most of what #100 is asking for

[jsjohnst]

as an example of the use case:

https://github.com/jsjohnst/lita-pagerduty/blob/master/lib/lita/handlers/pagerduty_utility.rb#L20

[jimmycuadra]

Thank you for the PR! This is a great idea I had never considered. I have only two hesitations compared to what I originally had in mind with regards to #100:

1. It still requires the plugin author to define the route in a special way in order to allow the user to override it. Ideally users would be able to arbitrarily override route conditions no matter how the route is defined.
2. Potential overhead of evaluating many procs at runtime when a message is received. If the proc is only being used as a workaround for regular expressions that can't be constructed until some user-supplied configuration value is known (as in @jsjohnst's example), then it's redoing the same work every time a new message is received. It'd be much more efficient to have a phase during the robot's start up where the procs get called once and converted into the regular expressions that will actually be used to do the matching. If there are other use cases for this where a single-pass evaluation of the proc isn't sufficient, that might not be possible, but I'd like to hear about those cases.