Document safety of cfood.yaml w.r.t. code injection

The discussion from #25 (closed) lead to the following conclusions

We have to specify why macros and defining custom converters can be done safely w.r.t to injection of malicious code
One important part is that both are defined within the cfood.yaml, i.e., it is human-readable which code is loaded
The macro functionality is very limited. There are no ifs or loops (except for using macros in macros, maybe?), no actual code can be executed. Worst case, Stackoverflow an system running the crawler.
In the future, we'll offer the possibility to expand macros and then safe the resulting yaml, so depending on the level of paranoia, a cfood.yaml with macros could be expanded to one without before being roled out on a productive system.
Cfood definition itself has to be trusted by the users anyway since using an untrusted cfood can easily lead to data loss/corruption
Converters have to implement a specific interface, so it's unlikely that "by chance" malicious code can be loaded instead. Otherwise, custom converters are code that has to be run, so they should be trusted anyway.

DoD