Comando para o TDC e logger de chat adicionados
Adiciona o comando `!doc`.

A arquitetura nova se mostrou extremamente problemática tanto em termos
de organização e manutenção quanto em termos de testabilidade.

Por mais que eu aprecie o uso do `cache` do require para comparlhar
objetos através de módulos, é preciso perceber que da forma em que os
comandos estão organizados agora, fica um pouco chato de escrever testes
pra eles (uma coisa é dividir um EventEmitter e outra completamente
diferente, é acoplar um único EventEmitter a todos os módulos na mão).

Eu entendo o ganho de flexibilidade de fazer as coisas dessa forma, mas
a lógica de comandos fica diretamente acoplada à lógica de IO. Mudanças
no `bot`, no `helper` (me abisma um pouco que o acesso às respostas - o
output _per-se_ das funções é feito por meio de um módulo chamado
`helper`) ou no `EventEmitter` compartilhado vão fazer todos os comandos
mudarem sua lógica de saída.

Isso é um problema recorrente em codebases de node.js (acoplar a lógica
com o IO), afinal, o método padrão de programação com callbacks
sobrecarrega o input das funções (os parâmetros) com o output (pelos
callbacks). A longo prazo isso tem custos grandes, o que explica a
existência de alternativas como promessas ou fibers. Essa discussão não
é diretamente ligada a o que estou criticando na arquitetura, mas ela
carrega alguns pontos em comum.

Gostaria de propor mudanças à organização (e as executar), se possível.

Quanto ao código adicionado por esse commit, a ideia é relativamente
simples:

Um usuário manda a mensagem `!doc [token]` para o canal e o bot responde
com a documentação trimada desse `token`. Um `token` seria algo como:
`http.Server` ou `child_process`. O comando faz um request (que poderia
facilmente ser evitado com caching diário ou algo assim, para
performance) para `http://nodejs.org/api/module.json` e parseia o output
fazendo uma busca simples pelo token.

Hoje, ele pode buscar por métodos, classes, propriedades, eventos e
seções (por exemplo: `vm.caveats`).

Há coisas que eu gostaria de melhorar e discutir. O parsing de links não
é feito da forma mais elegante possível e estou incerto sobre o tamanho
máximo da documentação enviada. Mas só o fato de ele mandar o link já é
um bom avanço e cobre a maior parte do use-case desse comando.

Dê feedback, merge quando quiser, ainda posso mudar o que for preciso e
adicionar mais coisas. Tentei me ater ao estilo proposto o máximo
possível Tentei me ater ao estilo proposto o máximo possível, mas sei
que tenho hábitos fortes de estilo, então qualquer coisa fora da norma
ainda pode ser mudada.