Mark project releases as "to be updated" only if commits happen there

The newly ported package-release-nodes.php script uses a sophisticated query to determine if a package *might* be considered for being repackaged. While we probably won't get rid of the query, we can make stuff more clean and robust by not checking the mtime of exported files for triggering a repackage, but rather remember when changes are committed to a project. versioncontrol_project already retrieves affected projects on hook_versioncontrol_operation(), we just need a way to relay that information to versioncontrol_release.

The project_release module provides a nice table column named {project_release_nodes}.rebuild which formerly specified whether the CVS "tag" referred to a branch (rebuild = 1) or a tag (rebuild = 0). We don't use that anymore currently, since we're now using {versioncontrol_labels}.type instead for retrieving if a release. So I thought, let's reuse the rebuild field and fill it with values that actually indicate whether the release tarball should be rebuilt *just on the next* run of the packaging script.

Let's have a little example to demonstrate what I mean:

• User creates a release for branch DRUPAL-6--1. The "rebuild" property is set to one.
• Packaging script runs, selects the new release for packaging, makes a tarball out of it, and sets "rebuild" to 0.
• Packaging script runs again (cron), and doesn't even consider the release for repackaging as "rebuild" is 0.
• Consequently, no rebuilds will happen as long as no commits happen to that branch. That saves us about a million cycles of "cvs export" & comparing exported file timestamps with {package_release_file}. As a bonus, we also can skip (left) joining {project_release_file} and {file} into the SELECT query.
• User commits into DRUPAL-6--1. versioncontrol_release takes note of that commit, and sets "rebuild" to 1.
• Packaging runs again (cron), and repackages the release because "rebuild" is 1 again. Makes a tarball, and resets it back to 0.
• Continue ad infinitum.

Actually, I currently prefer not to reuse the "rebuild" column from {project_release_nodes} because it's a branch/tag/packaging-script specific property and thus should go directly into {versioncontrol_release_labels}. Let's leave it to cvs.module to store its VCS specific data in other modules' tables.