Always use latest datestamp for project, not just the first one

When I'm using CVS deploy with update.module on Drupal 6, I have been bothered for the longest time that Drupal keeps telling me that I my 6.15-dev version of Drupal core is outdated and 6.14 is the latest security update, which is not true at all. Did a little digging into this:

1. update.compare.inc uses the datestamp to determine if a dev release is up to date:

        // If we're running a dev snapshot and have a timestamp, stop
        // searching for security updates once we hit an official release
        // older than what we've got. Allow 100 seconds of leeway to handle
        // differences between the datestamp in the .info file and the
        // timestamp of the tarball itself (which are usually off by 1 or 2
        // seconds) so that we don't flag that as a new release.
        if ($projects[$project]['install_type'] == 'dev') {
          if (empty($projects[$project]['datestamp'])) {
            // We don't have current timestamp info, so we can't know.
            continue;
          }
          elseif (isset($release['date']) && ($projects[$project]['datestamp'] + 100 > $release['date'])) {
            // We're newer than this, so we can skip it.
            continue;
          }
        }

2. When merging all the modules together into 'projects' in _update_process_info_list(), it doesn't check to make sure the datestamp is always the maximum value. It just uses the first value it gets, which is usually block.module, which also usually isn't a module updated in security releases.

    if (!isset($projects[$project_name])) {
      // Only process this if we haven't done this project, since a single
      // project can have multiple modules or themes.
      $projects[$project_name] = array(
        'name' => $project_name,
        'info' => $file->info,
        'datestamp' => isset($file->info['datestamp']) ? $file->info['datestamp'] : 0,
/****** ^^^ Uses only the first datestamp value it sees. */
        'includes' => array($file->name => $file->info['name']),
        'project_type' => $project_name == 'drupal' ? 'core' : $project_type,
      );
    }
    else {
      $projects[$project_name]['includes'][$file->name] = $file->info['name'];
      $projects[$project_name]['info']['_info_file_ctime'] = max($projects[$project_name]['info']['_info_file_ctime'], $file->info['_info_file_ctime']);
/**** ^^^ Should always get the max datetime like the _info_file_ctime here. */
    }

3. On my fresh CVS checkout of Drupal CVS 6.x branch (using CVS deploy, which gets the actual datestamps of the files):

module  datestamp
block   1246487532
system  1253911601

4. So because of #2, the 'drupal' project gets assigned a datestamp of 1246487532, while the 6.14 release of Drupal has a datestamp of 1253130028. The datestamp of our local 'drupal' project *should* be the maximum, in this case 1253911601, which would then be classified as up-to-date.