Listener Middleware

Builds on #801 (57b722022807b9a5befaafcab2442ad3a03d455b) to allow injecting arbitrary code between the Listener match and execute steps. Like in Express, middleware can interrupt the response process, preventing the Listener callback from ever being executed. Middleware can perform operations both on the way towards the Listener callback (before callback execution) and on the way away from the Listener callback (after callback execution/middleware interrupt).

As a side effect, listeners are now executed asynchronously. Behavior around message.done should remain the same (process until message.done is true).

Example usage (imposes authorization policy on all scripts): https://github.com/michaelansel/hubot-rbac/blob/master/src/rbac.coffee
I thought about this while writing the code and decided it might make more sense to require each piece of middleware to explicitly handle its own errors. Otherwise, hubot needs to decide what to do when an exception is thrown:
- pretend like the piece of middleware called `done`, which would execute wrapped `done` callbacks on all earlier middleware
- ignore all wrapped `done` callbacks and short circuit to the `done` callback provided by `robot.receive`
- stop processing completely (don't attempt further matches) -- this is what will happen right now due to the global uncaughtException handler

The first option is not wrong, but the third seemed sufficient for the reason you mentioned: not sure exactly what should happen for a non-uncaughtException.

I'll stare at this a little bit more this week and see if I can come up with a clean solution.