Verifiable chain of custody of artifacts using cryptographic GPG signing

[See original issue on GitLab](https://gitlab.com/BuildStream/buildstream/-/issues/333)
In GitLab by [[Gitlab user @tristanvb]](https://gitlab.com/tristanvb) on Mar 31, 2018, 11:15

This was [proposed once](https://mail.gnome.org/archives/buildstream-list/2017-October/msg00004.html) in October and the initial proposal for this was [shot down](https://mail.gnome.org/archives/buildstream-list/2017-October/msg00005.html).

We will probably be seeing a new proposal for this, which I think should:
* Treat GPG signing as a built-in first class feature, benefiting users from it's inception
* Be considered as a *chain of custody* feature, starting with capability of signing the artifact in `bst build` and verifying the artifact in `bst pull`
* Be designed with only the artifact as a dependency, such that it is not tightly coupled with the backing storage type of the artifact (e.g. currently `tar` or `ostree`)
* It's possible to have artifact storage backends participate in the process, using well defined APIs which an abstract artifact cache needs to implement
* Perhaps this is another reason for BuildStream to grow it's own understanding of *merkle trees* for artifacts, if we need to generate and manage *merkle trees* for other reasons, it would stand to reason that we could use these for the purpose of quickly signing checksums of files in artifacts, rather than content.
* Consider plausible future extensions to expansion on the chain of custody, such as:
* Tester wants to *promote* an artifact to a tested repository, after signing it with their special seal of approval
* Have some practical management of verification keys, probably at the project.conf level
* It may make sense to have this implemented with a separate keyserver referred to by a project.conf, such that keys can be revoked without requiring users to `git pull` their BuildStream project repositories in order to discover a new `project.conf` and key chain.

Start with the linked GitLab issue and the referenced October mailing-list proposal and response. The issue names bst build, bst pull, project.conf, artifact storage backends, and key management, but no files or tests. Done is not bounded: a new proposal and design would be needed before implementation could be assessed.

Written by the indexing model from the issue text.