Add an alter hook invoked while generating release-history XML files

Here are the suggestions I posted in #1549000: Convert XML generation to an API:
1) Move the update XML generation to a separate project to improve maintainability (in case a new Drupal version changes the XML specification) and to make it easier for people to set up their own update server.
2) When doing so, make sure the XML generation code is a true API: it should work with passed on arguments only and not depend on the database for getting update information. This allows the code to work with information from other sources than Project.module releases. Generating the data structure and the XML should happen in two separate functions, to allow the data to be output in another format as well, e.g. JSON.

Some more suggestions based on this issue:
3) The alter hook is a great idea. However, don't pass on SimpleXML objects. Instead, standardize the data using classes and pass the object structure on to alter implementations, because they shouldn't care about the XML. The built and altered data structure can then be rendered through a different function (see suggestion 2).

Summarized: Separate update data generation project & separate update data generation and render functions.

With "[update] feed", I meant the XML output that contains project information according to the format used for Drupal (is there a DTD for this? There should be!)

The current code that generates this feed is specific to how project_release.module stores its project data: in {project_release}. However, there may be people who want to provide an update feed that pulls its data from another source: different DB tables, or perhaps files stored on disk. This is why I suggest to rewrite the feed generation code to use content from function arguments and not from any other external source. The DB may be used, but for configuration and not for loading feed content (unless by an external function that calls the update feed API). This will add abstraction, but not to the level where the code just renders an array to XML. I don't think using arrays to store data is a DX-proof way. I'd suggest to use objects for this. They will be easier to document and understand, and the code handling them will be easier to read.
Also, instead of setting human-readable names (which is wrong enough in itself), we should pass on objects as well (term objects instead of term names, for instance). This will provide the alter hook with more context.

I hope that the above paragraph does a better job at explaining my suggestions than my previous post. I also hope that it shows why we might want to move the feed code to a separate project: if it no longer depends on project_release's data, why should it still be part of the project? It may be a lot more useful if we give it a place of its own.

This is needed for #2853696: Add security advisory coverage to update status XML.

Around the D6 deprecation, we had a need for altering the XML, and SimpleXMLElement and an alter hook has been working well. The release-specific bits are still string concatenation.