Issue status changes should be check_plain()ed, not just filter_xss()ed.

cvs archeology pointed to issue archeology, which pointed here:
#219734-4: Allow theming of changes in project issue table and email
aclight:

Instead of passing the stuff that will go into the tables through check_plain(), I'm now passing it through filter_xss, allowing for a, strong, and em tags. This will pave the wave for potentially allowing links in the metadata table (eg. to a username or something like that), which would be nice.

The function doing this filtering is theme_project_issue_comment_table_row($field, $change). So, we could either:

A) Implement our own version of this in bluebeach that had a special case for $field == 'title' to use check_plain() instead of filter_xss().

B) Change the upstream version of this to special-case check_plain() for $field == 'title'

Keep in mind, this themeability was added exactly for cases like #314326: Issue tagging and YOU! so that the tags associated with an issue could appear in these tables as links to the pages for each term, for example...

I think it makes sense to special case $field == 'title' so that the value is check_plain()ed. I don't see how doing that would cause problems on other sites using project*, and in fact should prevent the same problem described here.

a) For consistency, we want to special-case the project title (pid), too, since there's nothing stopping people from putting tag-looking stuff in their project titles, and everywhere else that's just check_plain()'ed.

b) This was more of a pain in the ass then it probably should have been, since the summary table at the top of the issue is handled by different code than the change summary tables. Not sure if it'd be even more of a pain in the ass to try to refactor things so those could be using shared logic, since they're doing different things.

c) I looked at the other possible things that could be changing, and the only other field I could find which should have similar treatment is version (rid). On sites that allow direct creation of release nodes instead of using cvs.module, someone could enter markup in the version field. In the release download table on the project node, and in the form selector for choosing an issue version (the only public-facing spots the version field is displayed), the version string is check_plain()'ed, not filter_xss()'ed. I didn't find any other fields that should get similar treatment. I discovered that if you put markup in a component, you can never select that component due to FAPI validation weirdness, but that's a separate bug. Usernames can't have markup at all in the first place. category + priority are hard-coded (for now), etc.

Now deployed on p.d.o. Looking proper: http://project.drupal.org/node/343020

Fixed typo in a few code comments.

The code looks good to me, but haven't tested.

I'm not convinced that we should be passing the rid (version name) through check_plain() here, but as dww pointed out in IRC this is a theme function so if a site owner wanted to use filter_xss() instead he could override the theme function.

Committed to DRUPAL-5--2 + HEAD. Deployed on d.o.