Clear TranslationMessage.potemplate fields for source_file_format == XPI

Doing this as an addition to the message-sharing-populate script.

This only affects some 25K messages; should be no trouble performance-wise to do it in one SQL query à la...
{{{
UPDATE TranslationMessage
SET potemplate = NULL
FROM POTemplate
WHERE
    POTemplate.path LIKE '%.xpi' AND
    language = 119
}}}

Doing so currently violates no unique constraints either, but it may cause duplications that we don't currently check for.

We do seem to have some 70K "en" TranslationMessages in the database that are not from XPI templates. We should probably delete those.

Ahem. Slight omission in the example query above, of course: POTemplate.id = TranslationMessage.potemplate. So it becomes
{{{
UPDATE TranslationMessage
SET potemplate = NULL
FROM POTemplate
WHERE
    POTemplate.id = TranslationMessage.potemplate AND
    POTemplate.path LIKE '%.xpi' AND
    language = 119;
}}}

The update currently creates no duplicates and takes about a minute to run, updating 25K rows.

As could be expected, the number of diverged "en" messages from XPI templates has gone down through natural attrition—fresh template imports produce shared English "translations."

Looking at just the current-or-imported messages for current templates, the numbers are:

 - 11397 messages in Hardy
 - 5706 messages in Intrepid
 - 0 messages in Jaunty (though still 2 non-current, non-imported diverged messages)
 - 2082 messages in midbrowser trunk

Does this bug still matter? Or should we just let it go away by itself?

The bug pretty much goes away by itself.