[feature-request] Support sparse-checkout

[aaronplusone]

git 2.25+ allows tracking of partial repository directories through sparse-checkout. This is useful when a project needs only a limited set of packages in a monolithic repository. E.g. swri_yaml_util in swri-robotics/marti_common.

I've been working on a branch to adapt vcs to do sparse-checkouts for our CI/CD pipeline. If you approve of the approach and are comfortable accepting git specific functionality, I can make a PR.

Proposed changes:

YAML

• New "subpaths" key specifies sparse-checkout patterns for repository. Key is the same level as url/uri.

Example from above, with a second package specified.

# VCS Format
repositories:
  marti:
    type: git
    url: https://github.com/swri-robotics/marti_common.git
    version: master
    subpaths:
      - swri_yaml_util
      - swri_console_util

import_.py

• Add subpaths member to ImportCommand
• Parsing logic for subpaths in get_repos_in_vcstool_format and get_repos_in_rosinstall_format
• Include subpaths in generate_job

Git Client

• Add check for git version > 2.25.0 when "subpaths" key is found in import/export
• Import
  • Match sparse-checkout patterns when determining if existing repo matches yaml specification
  • If subpaths in command
    • Clone with --no-checkout
    • Initialize sparse repo with --cone
    • Set sparse-checkout patterns to space separated list of subpaths
    • Verify that subpaths exist in final repo, warn if they do not (to protect against typos in subpath specification)
• Export
  • Add subpaths (if any exist) to export_data key

[130s]

+1

I discussed offline with @aaronplusone and suggested:

• Backup compatibility: i.e. the tool should not fail when 1) the option to trigger the new feature is not passed, 2) the underlining functionality is not available in non-git vcs tool.
  • For non-git, handle unimplemented feature and behave the same way that the tool works without the option.

[aaronplusone]

+1

I discussed offline with @aaronplusone and suggested:

* Backup compatibility: i.e. the tool should not fail when 1) the option to trigger the new feature is not passed, 2) the underlining functionality is not available in non-git `vcs` tool.
  
  * For non-`git`, handle unimplemented feature and behave the same way that the tool works without the option.

At least for git, adding a key prior to this PR would still clone the repository if the rest of the yaml entry was correct. I'm assuming cloning in other version control systems would work the same way. Assuming it does, is it better to pull in the entire repo or to fail? I could see cases for either.