Introducing triggered services.

ScoringService, PrintingService, ProxyService, and EvaluationService
have all a similar pattern (getting notified of object that needs an
action, and running a sweeper to catch missing object). This commit
introduce an appropriate base class, TriggeredService, that takes care
of setting up these mechanisms.

It also make all these services use a single priority queue (similar
to what ES used), extracting it to a reusable and tested class.

More in details. The real work on the operations to perform is
delegated to "executors", who have a single method to override,
"execute". Inside an executor, there is a priority queue of operations
to perform, and the executor sequentially picks from the top an
operation to execute (or with a configuration, can also execute all
the operations currently present in the queue at the same time).

A triggered service can have one or more executors. Each time an
operation is enqueued, or a missing operation is found, the operation
is enqueued in the queues of all executors.

In practice, the priority queue is necessary only for ES, but its nice
to have also for the other services (apart Proxy that executes all the
operations at the same time, and is therefore the only client of the
batch mode of execution). Proxy is also the only service using more
than one executor, one for each external ranking.

Nonetheless the model gives some flexibility to do additional change
in case we will need them, for example: an ES that can handle more
than one contest, and with a pool of workers assigned to each, could
have n executors, each ignoring the submission for other contests.
Is this loop finishes by exception for purpose? Shouldn't it be like:
while not self._operation_queue.empty()
...
?