o !votekick und !kick müssen best. kickfunktion aufrufen. die kann dann
   kickban und nach 3 sec unban oder sowas machen.
 o benutzergruppen; z.B. votekick-wahlberechtigt?

 o ein plugin soll auf verschiedene commands ansprechen können
   (z.B. !kick, !kickban etc)


 o neuladen von listen + conf via plugins
 o listenfunktionen: add/del z.B.(useradd, userdel)
 o bot forken lassen (damit nohup wegfallen kann)
 o user per nickserv identifizieren, alternative: passwort
 o alle plugins sollen configfile nutzen


 o bannlisten??? (mode #channel +b)

 o einige sachen können mit maps besser gelöst werden
 o DrunkenMan[,:] do_sth statt !do_sth als befehl-prefix
     channel und session ist dafür relevant
 o slot- oder hook-konzept: plugins senden nicht mehr "KICK :foo", sondern
   rufen parent->do("KICK", arg1, ...) auf
   returnval: -1=no such hook, -2 .. -inf = error, 0..inf=ok
   einige dinge, wie kick, ban, kickban, stellt drunkenman selbst bereit
   diese, und alle undefinierten können durch hooks überschrieben werden
   so kann z.B. drunkenman's kick nur kicken, ein spezielles kick aber
   noch für 3 sec bannen, um autorejoins zu vermeiden
   
   plugins können folgendes tun:
   if (parent->do("timedkick"...)<0) parent->do("normalkick")
   
   ODER:
   plugins stellen hook(string what, void* data, TConnection* parent)
   bereit, und sagen in init, was sie können (kann auch "nichts" sein)
   wenn nun ein plugin als "KICK" eingetragen ist, wird statt
   dm's eigenem kick dieser hook gerufen, mit allen infos über den
   momentanen verbindungskontext.
   -> plugins können auch später noch darauf reagieren
   
   außerdem können hooks "antworten". dafür wird ein weiterer
   exe-grund erstellt, nämlich REASON_ANSWER. den können plugins
   nicht ignorieren.
   so kann z.B. "is_master" erst einen whois starten, und erst dann
   antworten, wenn der whois durch ist.