allow editing HEAD-based releases to point to a new branch

(moving this from http://drupal.org/node/86863, under the heading "release nodes that are pointing to the TRUNK"):

whatever release node is pointing at HEAD (dev snapshots from the trunk) will have a fixed nid. this nid will be stored in any issues refering to it in the issue queue, and in any other references to these particular development snapshots. at any given time, the HEAD will be compatible with a particular version of core. it'd be nice to be able to give regular project maintainers permissions to move the branch this release node is pointing to when a more appropriate branch exists. an example should clarify:

say, you've got a release node pointing to HEAD for some module that hasn't been fully ported to the 5.x API yet. the version number for these snapshot releases is currently "5.x-0.0-dev" or something. eventually, it's done being ported, and the maintainer creates the "DRUPAL-5" branch. it'd be nice to just change the existing "5.x-0.0-dev" release node to start doing snapshots off the DRUPAL-5 branch, instead. why? because the version field in issues are really stored as the node id (nid) of the associated release node (that's basically how it works now, only it's a release id (rid), not a nid).

it'd suck for all the issues that were marked against "5.x-0.0-dev" (e.g. issues currently marked "cvs") to just automatically jump to being labled 6.x-0.0-dev if you changed the version number on the existing HEAD node. it'd be better that once created, the version number on a release node basically has to stay fixed. but, in the special case of the branch pointing to 'HEAD', it could be moved to point to a more appropriate branch, once the branch was created... then, they could create a new release node pointing to the HEAD, with "6.x-0.0-dev" as the version, and that would show up as a different option in the version field in the issue queue.

so, basically all we have to do is that for non-admins, when editing a release node with 'HEAD' as the CVS branch, we'd just query the {cvs_tags} table for this project, and see if there are any tags that match the same version info that's currently in the release node (API compatibility taxonomy, major version, etc), and if so, provide that as an option in the "CVS branch" dropdown along with 'HEAD'.

release nodes not pointing to HEAD should never have their branches or tags changed by regular project maintainers...