dpkg: Introduce a new dependency try level for trigger processing

The introduction of dependency satisfiability for trigger processing,
which was in the original spec but not the implementation, there has
been countless problems with bogus detection of trigger cycles.

The problem is that whenever we try to process triggers for a package,
we might not be able to due to dependency unsatisfiaiblity, which means
we have to put the package back into the queue. If we add the state into
the cycle detection tracker, then multiple visits to these packages will
hit the cycle detection for artificially generated cycles. But we cannot
avoid performing the checks because that will miss dynamic cycles coming
from maintainer scripts, for example.

To avoid most of these problems (while possibly not fixing all potential
ones), we should delay trigger processsing entirely until we have
emptied the processing queue as much as possible. We do that by
introducing a new dependency try level, after the dependency cycle
breaking one.

We will also make the trigger cycle detection unconditional of the
dependency try, because for the trigproc try-queued it will not matter
anymore as we will only ented on higher dependency tries, and for the
other trigproc types we should not care about any queue-specific
dependency try level.

Closes: #810724, #854478, #911620