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.
Fix lint in the tdc command.

JShint warning 101 is the line too long warning.