Remove AtomPipeline, add helper in its stead

What does this MR do and why?

Remove AtomPipeline, add helper in its stead; this was not a consistent concept to carry in the codebase. See AtomPipeline mixes parse- and render-time conce... (#594691), which this closes. We also patch a hole in the issue-to-work-item migration, restoring summaries to work item feed events.

This MR means:

• Issue/MR Atom event sites now correctly rely on the cached description HTML, instead of re-rendering from scratch each time.
• Atom render-time decisions are configured in one place, instead of spread across sites and being in a pipeline whose results are never cached; the only pipeline of its kind at that!
  • Events::RenderService is now a bit more findable, since it relies on the same shared Banzai::ATOM_CONTEXT.
• "Work item" event sites have summaries now, like issues do.
• data-sourcepos now appears in these output sites. This is not a problem, anticipated, and consistent with the remaining Atom sites.

See also stacked MR Use absolute links in Atom feeds by consolidati... (!248652).

Screenshots or screen recordings

No visible change.

How to set up and validate locally

1. Create a new issue in your GDK, in a public project. Mine looks like this:
   
2. Go to your own user's Atom feed (note the event is visible on this page):
   
3. Observe the feed entry. Notice the <summary> is empty:
4. Check this branch out.
5. Refresh the feed.
6. The feed entry is still there We also get a <summary>!
   

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.