Add design for package management system

[thanethomson]

As per the conversation on #48, we're probably going to need a package management system for Themis Contract templates. Before we can design it though, we're going to need to decide on:

1. The file system/folder structure for what constitutes a template.
2. The file system/folder structure for what constitutes a contract.

Perhaps (1) and (2) above will be the same. My feeling is we're going to head in a similar direction (conceptually, not in structure) to how DOCX and ODT files are structured: as a package that contains files that are organized into standardized folders.

[thanethomson]

We've decided here to make use of the following approach to package management in v0.2 (currently on branch prototype/v2, soon to be merged to master):

1. Each profile can have a single Git repository associated with it as its "contract repository".
2. themis-contract profile contracts sync will download/update its local cached copy of this repository.
3. themis-contract profile contracts list will list all contracts in this repository. Themis Contract recursively scans the locally cached repo for contract.dhall files and assumes that, if it finds one in a folder, that that folder is a contract. It currently skips hidden folders and any folders with the prefix example.
4. themis-contract new contract-id will automatically detect, for the currently active profile, whether contract-id is a contract available with your current profile and create a new contract using this detected one as its upstream.

We initially thought to detect contract "templates" (i.e. upstreams) by way of their suffix, using contract.template.dhall to define a "template" as opposed to contract.dhall. This, however, conflicts with how several other parts of the system work. It might still be a good strategy, but the work involved to implement that change may not be worth the effort right now.