Refactor version selection box to leverage "version strings" instead of "release strings"

This seems like a great thing to fix as part of the D7 rewrite. We don't have to re-implement versions for issues exactly the same way in D7 as we do in D6. We've got a free hand to start over with a clean slate and make it both more flexible for other sites and to make life better for the test bot on d.o.

In addition to everything jthorston is saying here about the test bot, a few other reasons *not* to keep using a release node ID to represent the version:

- It'd be really nice for sites that just want issue tracking and not releases to still define version choices for their issues. It could work a lot like components do now: you just have a field on the project node that holds the allowed values and you just declare them manually however you want.

- If you have the same version string in multiple projects and you move the issue from one project to another, we currently show that the version changes from 7.x-1.x-dev to 7.x-1.x-dev, which is a bit of a UI WTF.

- Sorting an issue queue by the version field actually sorts by release nid, not the actual version sort. See #177523: Sorting of versions in project_issues table not in correct order.

- Similarly, the sort of version choices in the version selector is wonky. See #767366: Sort version lists with version_compare().

- There's currently *NOTHING* in project_issue that takes advantage of the fact that we store release node IDs here. So, we store the data in this counter-intuitive way that makes trouble for us in various places, but we don't use it for anything. ;) If we *did* need to see all the issues associated with a given release node (e.g. a block visible on release nodes or something), we could always use the version string to find a match. But we don't need to be storing it internally as a release ID for that to work.

Also, tagging appropriately.

this would be lovely...but there's a potential hiccup problem. git allows there to be branches and tags with identical names, as it internally namespaces them. e.g.:

refs/tags/foo
refs/heads/foo

because we strip the leading elements out (and store them as separate metadata), the ref names that would populate this box are potentially non-unique. it's possible that the filtering we do to only allow acceptable naming patterns would mean we don't have the problem, but those are a d.o one-off and so probably ought not be a justification for not handling this properly.

if project_issue wanted to go the route of prepending something to the identifying string across all situations (e.g., the above items are prepended with branch or tag to form 'branch:foo' and 'tag:foo' in the selector), then this would probably work. it just might mean some other, extra logic somewhere to deal with using those values to map them back to vcapi objects...maybe. i don't know if it that's ever necessary.

Given the info in comment #4 above, and after a discussion with @jthorson at the DrupalCon Munich code sprint, this issue is a nice-to-have, but not mandatory for the D7 upgrade given the tight timetable and finish line. Untagging.

This has been partially implemented, but not really. See #1665580-8: Add version field back to project_issue views for more.

See #1822310: Cleanup how the version field on issues works for cleanup.

#1665580: Add version field back to project_issue views is the parent issue from the D7 Upgrade.

See #1822310: Cleanup how the version field on issues works for the cleanup work.