Adding the first filter/action in an earlier priority during a later priority causes the earlier priority to run (last)

[devesine]

During testing of #21169, it occurred to me that ​http://core.trac.wordpress.org/ticket/5338#comment:1 might present a problem with each rather than next/current, but that turns out not to be the case. Instead, this exposed a different bug:

If you add a new filter at priority 9, when priority 9 did not previously have any filters, during the priority 10 execution, the priority 9 filter will run (!) after all other priorities (since the filters are not resorted after each priority).

(Generally, if you add an earlier priority that did not previously have any filters during a later priority...)

The attached unit test demonstrates this behavior.

[devesine]

Proposed solution: keep track of the current priority, skip any priorities encountered that are already past.

add-at-9-after-21169.patch​ applies after the patch attached to #21169; add-at-9-include-21169.patch​ includes that patch (for convenience of testing).

I can also write one against the present code (using next()/current() rather than each()) if/when that becomes appropriate. Doing it without the #21169 change would slightly change the implementation of this fix (to use key($wp_filter[$tag]) instead of $next['key'], I believe).

[DrewAPicture]

This seems like a duplicate for #17817 which has a roadmap for merge approval.