configconvert: convert service escalation to notification escalation logic

- fixed bug with contactgroups in plain notifications
- fix bug with duplicated notifications (duplicate detection logic based
  on names, not template names)
- contacts may use templates too, and hide required values there
  (commands)
- added attribute getters which take templates into account (required
  for service -> notification_interval multiplied with service escalation
  first|last_notification too)
- apply the service escalation -> users -> commands as well as linking
  new notification with users, and services, defined either with
  * host_name/service_description
  * hostgroup_name/service_description
  * servicegroup_name (TODO)
- code duplication due to many nested loops with group wildcards

in short - we know why icinga 1.x takes ages to apply escalation.
because they look like added under pressure, and make no logical sense
compared to the rest. in short - they suck.

refs #4009
configconvert: only export servicegroups when available

refs #2743
configconvert: serviceescalations with servicegroup_name

requires a new functionality to grab all service names by a given
servicegroup name. this only works after reprocessing all services with
their updated "servicegroups" attribute as array in the 2.x objects
hive.

after fetching the service names and their logical objects, it's quite
the same procedure as for the hostgroups and single
host_names/service_descriptions - for better reading, code remains
duplicated for now.

furthermore, escalation notification template objects are only added
based on the old contact->notification_command, and only a reference
template added when using within the service linking.

refs #4009
configconvert: rename unique notification object identifier

refs #2743
configconvert: remove trailing whitespaces
configconvert: notification* attributes for services and users

refs #2743