Logic for default plugin selection needs robustification

Currently, VersioncontrolRepository::getPlugin has the following logic:

    if (empty($this->plugins[$plugin_slot])) {
      // handle special case for two slots using the same plugin type
      if ($plugin_slot == 'committer_mapper' || $plugin_slot == 'author_mapper') {
        $variable = 'versioncontrol_repository_plugin_default_user_mapping_methods';
      }
      else {
        $variable = 'versioncontrol_repository_plugin_default_' . $plugin_slot;
      }
      $plugin_name = variable_get($variable, '');
    }
    else {
      $plugin_name = $this->plugins[$plugin_slot];
    }

There are two fundamental problems with this logic:

• It does not function properly in multi-backend environments; a sane default plugin that is git-specific will not be a sane default for svn.
• Other such settings tend to be handled primarily by registering them on the VersioncontrolBackend, then letting the backend object handle it. Makes for less code duplication. e.g. VersioncontrolBackend::verifyPluginInterface(). Moving it into a $conf var breaks the pattern.

Those are the really blocking problems; other less critical issues include the one-off code for the commit/author mapping using the same default, and...some other stuff I can't think of offhand.

In the long run, we'll probably want a cascading series of defaults so that the owner of the repo (e.g., versioncontrol_project) can specify defaults that don't interfere with other repo owners, but that's a >2.0 feature.