DropMessage refactoring: Don't use generic-parametered DropMessages

but ModelObjects as `data` field that shall be casted to specific target types afterwards.

Perhaps a reasonable way to get rid of the template-bracket-frenzy that's spread all over the code.
Please review and critizize - I haven't spent so much time in semantically walking through all the changes.

Resolves #199 once merged.
Having a getDataAs() method in DropMessage is. a. __terrible__. idea.

The problem with this approach is: ModelObject is intended to be used not only in DropMessage but in other places too. If the cast is implemented in DropMessage, you can only cast a ModelObject in a sane way if you also have the DropMessage too. If you want to give the modelobject to another type without casting it, you can't cast it there in a typesafe way. Also, if you want to use ModelObject i.e. for the storage (which I would suggest), you have to copy this function from DropMessage to the storage, which is code duplication, which makes you a terrible programmer and person.