Add "postrequisites" to fixtures - the inverse of a prerequisite

[laundmo]

A postrequisite is a fixture dependency which specifies that the postrequisite should run after the source fixture.
This in turn results in the postrequisite running before the source fixture for on_success

If i write a fixture A, which only has a on_succes that should run after the on_success of B, i can't make B a __prerequisites__ as those are sorted for on_request. This means as a prerequisite, B.on_success will run after my A.on_success, not before.

__postrequisites__ simply reverses this relation. B being in __postrequisites__ on A is the same a A being in the __prerequisites__ of B - and in fact, internally this is how postrequisites are represented while building the Directed Acyclic Graph.

This PR switches the custom topological sort to use graphlib instead, as graphlib detects cycles. graphlib is a new stdlib module since python 3.9, so graphlib-backport is added as a dependency for compatability with older python versions.

[mdipierro]

At the technical level this is a good PR. But it adds a lot of complexity and cognitive load to the users. Why is this needed? Let's discuss on the group.

[laundmo]

Well, in most cases it's relatively little extra, as prerequisites work the same way as before and most cases won't need postrequisites.

Perhaps I can revert some of the docs sections which mention postrequisites as they're truly only relevant in very few cases - mainly Template.

Template is also the main motivating factor: currently, there's no nice way to ensure a fixture is always available to Template, such as T (Translator) or flash which are often used in the layout and therefore a permanent dependency of Template.