FS#1981 - Unify event logging and notifications

They are currently two separate mechanisms. Shouldn't be so. Events happen always, notifications when someone should be or have chosen to be notified about those events.

Besides, the current code is just a total mess that should be fixed/rewritten anyway, and we unfortunately also overlooked during the development phase 2 things: one new table, users_emails, and the fact that the user is now allowed to give several email addresses separated by a semicolon.

You don't get my meaning. They are in reality not separate things, but in our current codebase, they are. Instead of having a separate table notification_messages, notification_recipients should be modified and a new column, history_id, should be added, that links it to the event someone should be notified about. Maybe some more, have to think about this one a bit more.

Then, move all formatting out of Notifications class to events, make it a class too. Notifications should handle only who is getting notified, how, in what language and either sending or storing the notification, not any kind of formatting of the message.

Some really far-fetched ideas, if I'd do this in C++/Java/C#. An abstract base class EventType, has some abstract methods for formatting, and one concrete final static method EventType::getEventTypeInstance($history_id), and a lot of concrete subclasses implementing those formatting methods for various purposes just for that one event type. At least it would be a different kind of mess compared to the current case: case: case: case: etc going on already near or above 1000 lines mess in 2 different places.