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.