LEDS refactoring

I noted an annoying bug/missing-feature in LEDS that limits the creation of new maps: monsters list is unchanged when you start a new map. That doesn't please the game engine that may end up with a large number of GOBs that sits outside of the level limits, triggering high number of movement failures, etc.
Voilà. Je m'attaque à cet agaçant problème des monstres-hors-monde qui ralentissent à l'extrême l'exécution de RunME. Un cas qui ne se produit que lorsqu'on construit une nouvelle map (plus petite) à partir d'un modèle qui contenait déjà des monstres. Avant de procéder au "filtrage" proprement dit, j'ai réorganisé un certain nombre des classes à travers les fichiers: si je dois sortir cscope pour trouver quel fichier contient GobBlock, c'est qu'il n'est pas dans le bon.
L'écran de sélection des fichiers à aussi eu droit à sa restructuration pour rendre le fonctionnement par "modes" plus clair tout en évitant les accesseurs redondants.

I've gone through some refactoring of the "WelcomeWindow" code (the part where you pick which file you want to operate on), mostly giving each "state" a dedicated function for its specific processing. That introduce some level of redundancy, but it will make the doxygen-navigation through the code more comfortable, with smaller functions and more precises "called from" relationships. I'm also preparing a modification of the "Block-based parsing" of command: most the issues I'm encountering in the Monsters-to-GobBlock link comes from the fact that monsters are kept in a vector while they should be kept in a list. Once in a list, I can keep long-distance iterators e.g. so that you can delete one object when the user says so or when it's cropped out of the new map.


PS: Some UML for this finally got uploaded, a bit late, since I'm moving to a new office, and I've had plenty of cardboards boxes with O'Reilly books in the house, stacks of magazines that wait for being relocated and such. I don't want cheap-mobile-phone-shot for