The Hubot Hipchat adapter uses the `envelope.user.reply_to` property as
the primary way for determining where a message should get sent. This
does not appear to be necessary. It is an abnormal pattern that doesn't
seem to be in any other popular adapters (Slack, Campfire). Perhaps this
was necessary on some older versions of Hubot and was never updated.

The `envelope.room` property seems to have all it needs to send the
message to the right place. Removing the `reply_to` logic simplifies
things quite a bit. This change also helps with hipchat#175 where messages
would get sent to the wrong origins for some long running processes if
the user happens to send a message in another room before the process
can finish.

The fix for the above problem in hipchat#207 broke the brain some. Typically,
in other adapters, the `message.user` object returned will be a
reference to the brain. Here, you can store data that you would want to
persist. By cloning this object it breaks that ability and can affect
plugins expecting that behavior.

Found this issue while working with the `hubot-pager-me` plugin. This
plugin assumes the `message.user` property is from the brain. When
doing things like `pager me as [email protected]` it assigns it to that
property where it should persist but does not. This does work in other
adapters though like Shell and Campfire.

Finally, one other added benefit these changes bring are a level of
consistency to the `user.room` property. When `changePresence()` was
called it would populate the brain and set the room to the JID version
which looks something like `[email protected]`. When a
message was getting handled it would filter the room through
`roomNameFromJid()` which would transform the room name to a friendlier
format like `foo_bar`. Now, the `user.room` property will always bet set
to the JID version.