Custom Events should only be stored in the reporting database

Current Situation

The event processort stores orders in an JobScheduler global parameter as a xml list. The events are also stored in the database in the table REPORTING_CUSTOM_EVENTS. The events that are stored in the database are use to restore the xml list after a JobScheduler restart. They are also used to show the list of events in JOC or to check the existing of an event with the Job {{JobSchedulerCheckEvents }}.
Events that are added by an event processor must be removed by the same event processor as only then the events in the JobScheduler param are available.

Desired Behavior

The events should only be stored in the database.

The evaluation of events with the event handlers or with xslt stylesheet transformation should use the events that are assigned to the JobScheduler instance where the event processor is running. The parameter job_scheduler_id can filter the events to events that are assigned to a specific JobScheduler instance. The value * will use all events.
The event processor needs access to the database and therefore can not run on the Universal Agent.

The job JobSchedulerSubmitEventJob will no langer add an order the event processor but will directly insert (action=add) or remove (action=remove) the event record to/from the database. The job needs access to the database and therefore can not run on the Universal Agent.

The Job JobSchedulerDequeueEventsJob will be removed as there are no queued events any more.