Major issue #1b: Move commit branches to the API module

Commit branches ("this commit was applied to branch xyz") are currently being managed and retrieved by the backends, mainly for the reason that Subversion doesn't have any notion of branches and tags, it's all directory structure conventions there (which are likely to be different in each repository, of course). All other version control systems - at least those that are relevant to us - provide branches and tags as a native concept.

The question for us is whether we should move a table structure like the following, plus the associated functions, to the API module:

db_query("CREATE TABLE {versioncontrol_commit_branches} (
  vc_op_id int unsigned NOT NULL default 0,  /* id of the commit */
  branch_id int unsigned NOT NULL default 0,  /* the above commit happened in this branch */
  PRIMARY KEY (vc_op_id, branch_id)  /* mind, there can (and will) be multiple branches per commit */
) /*!40100 DEFAULT CHARACTER SET utf8 */");

Benefits:

• Takes more code out of the backends, get_commit_branches() in particular. Less code in backends == easier to write (except for Subversion, in this case).
• Combined with Major issue #1, all commit query constraints can be done by the API module itself and we largely get rid of the performance problems, which fixes Major issue #2 (or at least downgrades its priority to normal).
• If Subversion manages to implement this correctly, we can have branch/tag history even when for revisions that happened before a file moved into the branch/tag directory.
• The API module can even more efficiently do forward file history, because it doesn't need to ask the backend if a file revision is on a particular branch.

Disadvantages:

• The Subversion backend will have to try harder if it wants to support the notion of branches and tags.

All in all, I think it's worth it. Let's tackle this once Major issue #1 is solved.