Add notifications_schema table & verify on daemon startup

[yhabteab]

This PR adds a new notifications_schema table to the database, which is used to store the schema version for notifications. It quite similar to the one used in Icinga DB, but with a small but important difference: the version column is of type TEXT instead of INTEGER as opposed to Icinga DB. Instead of using an independent integer versioning system that can't be easily determined to which Icinga Notifications version it corresponds, we will use the actual semver version exactly as its upgrade script is named. This way, we can easily determine which version of the upgrade script corresponds to which version of Icinga Notifications or at least to which version of the upgrade script it corresponds.

In order to prevent users from applying the upgrade scripts out of order or the same script multiple times, any upgrade script after Icinga Notifications v1.0 will have use an SQL procedure introduced in this PR, which will check if the current version in the notifications_schema table matches the expected one before applying the upgrade. If the version does not match, the procedure will raise an error and prevent the upgrade from being applied. For instance, if we have an upgrade script for version v1.1, at the top of the script we will have a call to the procedure like this:

CALL assert_correct_schema_version('v1.0');

This ensures that the current upgrade script can only be applied if the current version in the notifications_schema table is v1.0, which means that the previous upgrade script has been applied. If the current version is not v1.0, the procedure will raise an error and prevent the upgrade from being applied, thus ensuring that the upgrade scripts are applied in the correct order and that no script is applied multiple times. And of course, Icinga Notifications performs a check at startup to ensure that the expected schema version is applied before doing anything else, but it doesn't go through the notifications_schema entries to determine for missing upgrade scripts since that is supposed to be handled by the upgrade scripts themselves.

resolves #343

[nilmerg]

Focusing on the schema differences here: That the version column is of type varchar now suits me well, because I was already thinking about moving the schema authority to Web, because it's got this nice migration feature with Icinga Web v2.12 and most other configuration already happens in Web. So with respect to that, that's fine as it is the case anywhere else as well with this feature in mind.

I too find it confusing that the schema table of icingadb uses a integer that differs from the file name or product version…