Provide a better mechanism for sorting releases with version_extra defined: introduce version_extra_weight

No matter what way we go, I'm going to be solving this in the next day or two -- so assigning to myself.

After a good discussion with Earl about this and #642094: Move the code to build the query that drives project_release_find_latest_releases() into a shared helper function we came up with an even better option here. Although it's a bit of work, I think it's the best trade-off of complexity, accuracy, and flexibility:

D) We should introduce a new {project_release_nodes}.version_extra_weight field. This will hold an integer code for sorting different possible prefixes of version_extra. There could be an admin tabledrag UI to order the prefixes accordingly, and add others. Any version_extra value that doesn't start with one of the known prefixes would use a low weight so that those come "first" (and are just sorted alphabetically). This would effectively let us implement version_compare() in SQL. For example, we might have:

[unknown] = 0
unstable* = 10
alpha* = 20
beta* = 30
rc* = 40
NULL = 100 (i.e releases without extra are always last -- the final official release).

The actual values don't matter, just the relative order. So, in the query to sort releases on a given branch, if we wanted the newest/best releases first, we'd have the following ORDER BY clauses:
// We always want the dev snapshots to show up last.
$orderby[] = 'r.rebuild';
$orderby[] = 'r.version_minor DESC';
$orderby[] = 'r.version_patch DESC';
$orderby[] = 'r.version_extra_weight DESC;
$orderby[] = 'r.version_extra DESC;

Make sense? To pull this off, we'd need:
- UI for defining the weights (could punt for now and hard-code a mapping in settings.php or something)
- Schema change to add the new field
- Batching schema update to populate the new field based on existing values of version_extra and the mapping
- Code in project_release when we're creating/editing arelease node to compute the version_extra_weight based on the current value of version_extra
- Exposing this field to views

Should be relatively quick, especially if we punt the admin UI for now, and it should completely solve the problem in a flexible, accurate way. It's also going to make #642114: Compute and maintain the update status for every release node a lot easier.

Handles everything except the admin UI and exposing to views. Tested locally, works like a charm, both with the default mapping and a custom mapping in settings.php.

BTW, here's a mysql command from my local test DB. Notice that the nids are "out of order" relative to the proper sorting of the versions (in particular, the 1.3-unstable1 release):

mysql> SELECT nid, version FROM project_release_nodes WHERE pid = 9 AND version_api_tid = 5 AND version_major = 1 ORDER BY rebuild, version_minor DESC, version_patch DESC, version_extra_weight DESC, version_extra DESC;
+-----+----------------+
| nid | version        |
+-----+----------------+
|  25 | 1.3-final-rc-1 | 
|  21 | 1.3-rc2        | 
|  20 | 1.3-rc1        | 
|  24 | 1.3-unstable1  | 
|  19 | 1.2            | 
|  18 | 1.2-rc2        | 
|  17 | 1.2-rc1        | 
|  16 | 1.2-beta1      | 
|  15 | 1.1            | 
|  14 | 1.1-rc1        | 
|  11 | 1.0            | 
|  10 | 1.0-beta1      | 
+-----+----------------+
12 rows in set (0.00 sec)

Now with a fix to project_release_query_releases_by_branch() to use the new fields in the ORDER BY.

Tested locally and it's working great...

mysql> SELECT nid, version FROM project_release_nodes WHERE pid = 9 AND version_api_tid = 5 AND version_major = 1 ORDER BY rebuild, version_minor DESC, version_patch DESC, version_extra_weight DESC, version_extra DESC;
+-----+----------------+
| nid | version        |
+-----+----------------+
|  27 | 1.3-final-rc-2 | 
|  25 | 1.3-final-rc-1 | 
|  26 | 1.3-rc4        | 
|  28 | 1.3-rc3        | 
|  21 | 1.3-rc2        | 
|  20 | 1.3-rc1        | 
|  24 | 1.3-unstable1  | 
|  19 | 1.2            | 
|  18 | 1.2-rc2        | 
|  17 | 1.2-rc1        | 
|  16 | 1.2-beta1      | 
|  15 | 1.1            | 
|  14 | 1.1-rc1        | 
|  11 | 1.0            | 
|  10 | 1.0-beta1      | 
+-----+----------------+
15 rows in set (0.01 sec)

mysql> SELECT recommended_release, latest_release FROM project_release_supported_versions WHERE nid = 9 AND tid = 5 AND major = 1;+---------------------+----------------+
| recommended_release | latest_release |
+---------------------+----------------+
|                  19 |             27 | 
+---------------------+----------------+
1 row in set (0.00 sec)

At hunmonk's request, I added the following comment:

      // If the $prefix exists inside version_extra, we have a match. We use
      // === 0 to tell the difference between the prefix being at position 0
      // (start of the string) vs. strpos() returning FALSE (not found).
      if (strpos($node->project_release['version_extra'], $prefix) === 0) {

Otherwise, committed this to HEAD. Yee haw!

Back to active for the UI and views support, but at least #642112: Add a latest_security_release column to {project_release_supported_versions} and #642114: Compute and maintain the update status for every release node are no longer blocked. ;)

Let's fix the views support with a bunch of other columns over at #644258: Finish exposing {project_release_nodes} data to views
The admin UI now lives at #644262: Add UI for controlling the version_extra_weight prefix mapping

So, this is now fixed.