Clean up ThingMLCompiler and Context interfaces

[jakhog]

IMO, the ThingMLCompiler and Context classes have turned into a bit of a mess, with references to directories or other things being set all over the place. I think it is time to have another look at what those classes contain, and try to move some of their features to arguments in the methods where they are actually needed.

To provide some concrete examples of what is strange:

• SetInput/Output directory. I don't really know where the InputDirectory is used, and I think the OutputDirectory should be moved as an argument to either the compile-method, or where the generated code is written to actual files.
• Plugins/Tools are set by the registry when a new compiler is asked for. But those will not propagate when .clone() is called. Maybe it's better to ask the registry for them where it is actually used.
• Logging, I think there is at least three used ways of writing log output currently. That should definitely not be the case...

If you have experienced any other strangeness, feel free to post them here so we can fix it in a single sweep.

[brice-morin]

Not to mention Debug, which should be redone as a ThingML tool. Debug can be quite useful, but the way it has been done turned out quite messy.

The InputDirectory may be used indirectly by some annotation e.g. to include some files like this ../lib/my.file so that we can use relative paths. Though I am not completely sure, maybe we can the path of the thingml element another way. So we need to double check that one.