Fix #182 failing tests

[fdodino]

Resumen, ver #182

• para los tests de fullRepl, evitamos abrir un socket para conectarnos al diagrama dinámico (puerto 3000), porque los tests no lo consideran
• lo mismo para los tests que prueban solo la interacción con el diagrama generado ahora por wollok-web-tools (diagram.test.ts)
• en el caso de dynamicDiagram.test.ts que sí prueba toda la interacción del repl con el socket del diagrama dinámico, agregamos un finally para que cierre el server al final, ya que si tiraba error el server.close() no se ejecutaba y los otros tests que dependían de tener el puerto 3000 libre fallaban
• el más difícil de todos fue el run.test.ts, ya que el test del game confiaba en chai, a partir de recibir una función done como parámetro. No obstante, necesitamos cerrar el ioGame. Al principio fui por la propuesta de agregar un parámetro dryRun en las opciones del run, pero después se me ocurrió devolver el ioGame en la promesa. Con eso el test pudo poner un await, cerrar el ioGame a mano y luego testear que el juego anduvo correctamente. En caso de error logueamos el mensaje para tener una buena experiencia de desarrolladore. Para testear game creé un ejemplo más, y de paso adelanté la validación de la carpeta assets que estaba metida dentro del método eventFor.

La duda que me queda es acá:

  const currentHost = gameHost(host!)
  const currentPort = gamePort(port!)
  server.listen(parseInt(currentPort), currentHost)  // listen 1

  logger.info(successDescription('Game available at: ' + bold(`http://${currentHost}:${currentPort}`)))
  server.listen(currentPort)  // listen 2

¿está bien tener un doble listen?