bump development version number
Redis on 'end' event should not permanently unsubscribe handler

Redis clients, by default, will attempt to reconnect to the server when a
connection ends. The 'end' event is fired when each socket closes, and
does not indicate that the logical connection is permanently closed.

Previously, we unsubscribed from the input channel when the 'end' event
was received. However, this meant that when the connection was
automatically reestablished, message would no longer be handled by the
client.

Now, we no longer unsubscribe the handler, it's expected that the client
will reconnect and buffered messages will be sent at that time. Messages
will be sent to the error channel if there is an error establishing the
connection to Redis.

Issue: #9
polish examples
Project infrastructure improvements

- allow user choice in buster reporter and colors
- allow concurrent sauce labs test runs from travis
- test in Node 0.6 and 0.8
All integration bus extentions return the bus

Some modules did not previously return the integration bus. This change
adds that support and tests all modules to ensure compatability.
Rework pass/fail interceptor to use Sauce sub account
Provide a hint indicating the type of a channel

A handler sending messages to a channel should not care what the
underlying channel implementation is, however, it can be useful in
certainly situations to have a hint. Particularly for code that is
instantiating channels, it's not reasonable to assert the type of channel
by testing it's behavior.

Adding a 'type' property to formally constructed channels.  The values are:
- 'default' -> bus.channel()
- 'pubsub'  -> bus.pubsubChannel()
- 'direct'  -> bus.directChannel()
- 'queue'   -> bus.queueChannel()
fixed broken transform example

the transform example (which capitalizes an input string) didn't work for me (using `integration-0.3.1` and `node-0.8.17`). i believe this is because the translator, `String.prototype.toUpperCase`, is an instance method, and the translator is [invoked without a `this`-binding](https://github.com/s2js/integration/commit/9068264d57a8cbce2df5cc59ca60471c591699d6#L20R562). maybe it would be interesting to bind translator invocations to the message (or even the bus / routing context), and allow it to access the payload, headers, and other properties/methods via `this`? 
Merge branch 'patch-1' of git://github.com/RubyTuesdayDONO/integration into dev
polishing #12
Apply a sequenceNumber to inboundGateway messages
integration.js is now msgs.js

We're also now part of Cujo.js
Fix sauce credentials for repo migration
typo [ci skip]
release v0.3.2