Extend program and input specification

[lchladek]

Currently, program and input files can either be specified as a path reference or fetched from a HTTP URL. This proposed addition introduces Git submodules:

[inputs.gourd_cargo_toml]
git = {
  repo = "https://github.com/ConSol-Lab/gourd/"
  tag = "1.1.0"
  file = "Cargo.toml"
}

The resource (Cargo.toml) will be taken from the gourd repository, which will be added as a Git submodule in the current directory. (For this, the gourd.toml folder must be within a Git repository, such as is created by gourd.init.) Gourd should then take care of resolving this dependency; the benefit of this feature is that the gourd.toml folder becomes a fully self-contained experiment specification.

Another issue (#21) relates to adding compile script support.

[lchladek]

A quick note after working on this feature:

I'm changing the scope slightly such that Gourd knows how to interact with Git submodules but not create them and resolve URLs.

In the updated workflow, the user uses Git to add/register a submodule (a reference to an external repo that, when cloned, shows up as a subfolder in the parent). Gourd will be able to refer to these submodules by name, make sure they are cloned, and extract files from different commit SHAs.

Gourd will not:

• Store the URL of the Git repository used as a submodule (Git is in charge of this)
• Add submodules _(Doing this in the Git CLI is easy and will be documented in the manual)

Gourd will:

• Check that a named submodule exists
• Clone if the submodule is defined but not yet cloned (should it also pull?)
• Checkout within the submodule to get files from various tags/commit SHAs

Yes, this means that the user has to interact with the Git CLI. But anything else would be an cut-down reimplementation of its own submodule feature (and keeping track of named Git URLs is all that is).

[mgazeel]

See #22