Add an option for reposync plugins to store tag/commit relations optionally

@sdboyer: It would be great if you take a look at this patch before I commit it.

BTW the impact here is that now you can see the list of tags the commit is in on commitlog, that already shows all labels associations since #1043506: Use versioncontrol_handler_field_operation_labels views field handler to avoid operation duplicates

Actually the main reason I end up writing this patch is because I think versioncontrol concept of operation label encourage the backend to make associations between labels(as we defined them on vcs api: branches and tags) and operations. I mean, my main motivation is consistency with the requirements of the api.

So, if we really do not want to encourage this maybe it's a good idea to change main api: versioncontrol_operation_labels then should become versioncontrol_operation_branches on vcs api(i.e. rename table and views field).

An old issue I did not find when I created this issue that is a subset of this: #1072224: Add tags to operation label relations

About separating in two table I did not really see the benefit.

We do already provide a mapping of the tag to an operation, right?

Not really, we only store the tag, but we never create a operation tag nor we store the relation on operation labels table.

I would definitely be in favour to store the relation on the operation labels table, it would be really cool to figure out through commitlog which commits where to which branches(i. e. figure out when a commit is released).

I would say to not store an operation tag, or maybe only do it when we have a real tag(annotated/signed).

Let's do this optionally to avoid at least triple the rows on versioncontrol_operation_labels table.

Reflect current state.

Then, implement it at versioncontrol_git.

Let's see what bot thinks.

Still a little to do, patch later.

These patches should be working correctly.

Tests confirm git log parsing is working correctly(VersioncontrolGitDataIntegrityTests and VersioncontrolGitEventDataIntegrityTests passed correctly).

@sdboyer: Pending on your review to add these patches upstream.
Update: Sorry, still pending to teach the option value to the git backend.

Ok, now it's ready for review.

Here some hints about variables for versioncontrol_git git_default reposync plugin options:

// map branch relations: 0x01;
// map tags relations: 0x02;

// To replicate current behavior(only map branches) set the sync plugin options variable accordingly:
$conf['versioncontrol_repository_synchronizer_options_git_default'] = array(
  'operation_labels_mapping' => 0x01,
);

// To only map tags:
$conf['versioncontrol_repository_synchronizer_options_git_default'] = array(
  'operation_labels_mapping' => 0x02,
);

// To map both branches and tags:
$conf['versioncontrol_repository_synchronizer_options_git_default'] = array(
  'operation_labels_mapping' => 0x03,
);

Notice this behavior is not retroactive(will not remove already added branches/tags) to preserve data, but I'm open to suggestions.

After reviewing this again I added it to 7.x-1.x, the patch for versioncontrol_git still needs some work, so I opened a new issue for that: #1985426: Implement versioncontrol reposync plugin option to store tag/commit relations optionally.

Back to NW for D6 version.

Since 6.x-2.x entered in maintenance mode, this will not make it there.

Removing unnecessary tags.