Currently there exists a tension between what is best for developers (storing all tools in a single repository - e.g. ncbi_blast_plus or bedtools) and what is best for Galaxy users (storing a single repository per tool and collecting them together with a suite - e.g. samtools or gatk). More discussion here.

This pull request extends the semantics of .shed.yml in a attempt to resolve this tension and make the best practice for Galaxy users trivial to manage for developers. Previously each .shed.yml could only correspond to a single Tool Shed repository and it would collect all files in a directory (except an optional list of ignored files). This pull request extends the shed_create and shed_upload commands to allow .shed.yml files to correspond to any number of actual Tool Shed repositories each with fully customizable file includes and excludes.

While there is a great deal customization allowed - two new keys auto_tool_repositories and suite provide shortcuts to quickly and implicity define repositories for for each individual tool in the directory and build a suite for those. Consider the following (admittedly idealized) samtools example:

owner: "devteam"
remote_repository_url: "https://github.com/galaxyproject/tools-devteam/tool_collections/samtools"
homepage_url: "https://github.com/galaxyproject/tools-devteam/"
categories:
  - "SAM"
auto_tool_repositories:
  name_template: "{{ tool_id }}"
  description_template: "Wrapper for samtools application {{ tool_name }}."
suite:
  name: "suite_samtools_1_2"
  description: "A suite of Galaxy tools designed to work with version 1.2 of the SAMtools package."
  long_description:
  > SAM (Sequence Alignment/Map) format is a generic format for storing large nucleotide sequence
    alignments.   This repository suite associates selected repositories containing Galaxy utilities that require
    version 1.2 of the SAMTools package.  These associated Galaxy utilities consist of a Galaxy Data
    Manager contained in the repository named data_manager_sam_fasta_index_builder and Galaxy tools
    contained in several separate repositories.

This example assumes the .shed.yml file is placed in a "flat" directory with each samtools tool wrapper and planemo will create and update repositories for each individual tool given the specified templates in auto_tool_repositories. The suite key here will auto-generate a suite repository for all of these tools and will automatically created the corresponding repository_dependencies.xml to populate it with (this is generated during shed_upload and never needs to exist in your repository).

Again this example is admittedly idealized, but if auto_tool_repositories is not specified, a repositories list can be specified instead. There are some examples of this in the test data included with this pull request:

• This .shed.yml is a simple example of specifying custom repositories for individual tools.
  -This demonstrates complex inclusions files from sub-directories and renaming.
• This .shed.yml demonstrates complex inclusions files from sub-directories and renaming.

The test data also includes some more advanced usages of the suite key as well - specifically using it without auto_tool_repositories as a generic replacement for repository_dependencies.xml and adding additional dependent repositories in addition to the ones defined by the .shed.yml file.

Implements #26.