13B: Notices split into a writer and a presenter

[nikolaystrikhar]

What: Notices\Queue splits into Notices\Writer (words a notice, stores it under slug:type, behind the new Writer_Interface) and Notices\Presenter (the activate_plugins gate and the render-then-clear, bound by class name); Absorber::notices() returns the writer and Absorber::render_notices() resolves the presenter.

Usage:

// Reword every notice without touching where they are kept or how they are drawn.
$container->singleton( Writer_Interface::class, My_Notice_Writer::class );

Why this way:

The name was wrong and the class was two jobs. Queue never held the queue — Store does — and it answered both "what does this notice say" and "who may see the pending set, and is it gone once they have". A host already running its own notices library has an opinion about the first and none about the second.

Only the writer earns a contract. Nothing in the library dispatches on how a notice reaches the screen: the all_admin_notices trampoline is the presenter's only caller, so a host that wants none of our rendering takes that callback off rather than binding an implementation that does nothing.

The capability check goes with render-and-clear, not with the markup. It guards the clearing as much as the drawing, so deciding those separately would let a user who may not see the queue destroy it anyway, through a class that never checked.

No behaviour changes. It is a move, which is why it exceeds the usual source-file cap.

[d4mation]

I don't know if I'm 100% sold on the name Presenter, but I do agree with the overall split of concerns :)