Launchpad will try to update every bug watch on a bug tracker, even if the remote bug hasn't changed for years

For non-plugin bugtrackers, Launchpad will try to update every bug watch that hasn't been checked for > ~24 hours (or at all), even if the remote bug was solved years ago. For the plugin-enabled bug trackers this is less of a problem because Launchpad can ask the remote tracker whether or not the bugs have changed. However, the problem then is that less bug watches will be updated than is possible, thus:

 1. Launchpad selects 100 "needs updating" watches
 2. Launchpad asks the remote tracker whether they've changed since $date (the oldest lastchecked date in the batch).
 3. Launchpad discards the unchanged bugs (say, 25 of them).
 4. Launchpad gets the status of the rest.

This means that we're wasting a chance to get 25% of the bug watches that do need checking.

For the most part this isn't a huge deal because most bugtrackers don't have a huge number of bug watches. For the Gnome Bugzilla, though (if it were running the plugin) it would be suboptimal to only fetch 75% of what we're capable of dealing with (though the 100 bug watch limit is an arbitratry one).

This is even more of a problem for bug trackers (like the Gnome Bugzilla, in fact) which *don't* run the plugin, since we waste time and network resources on very old, very stale bugs.

Ideally, Launchpad should be smarter about how it selects its batches for processing. For example:

 1. Has it been checked in the last 24 hours? (If yes, discard it; if no, continue)
 2. Has its status changed in the last 30 days (an arbitrary number).
 3. If yes, add it to the list of bugs to be updated
 4. If no, has it been checked in the last 7 days?
 5. If yes, discard it
 6. If no, add it to the list of bugs to be updated.

This should reduce, to some extent, the amount of stale bugs being checked.