Make qualifiers extensible

[tomcoldrick-ct]

Currently we support a few qualifiers, implemented explicitly within our code. It would be convenient to be able to support more. The difficulty here is that they're a bit vaguely specified, and the API isn't used enough for much to have been actually done with them for us to abstract them generically. This makes finding a point to hook them in a little tricky. Users wishing to add custom qualifiers are also going to struggle, and will need to fork (or upstream changes to) this repository to add them.

Thankfully, at least one of our implementations (remote executing fetcher) offers a simple enough API to hook around! The Remote Executing fetcher works by building a command to run as an Action in a REAPI cluster. In this world, qualifiers may be implemented entirely as modifying this command generically. We can exploit this by allowing operators to write some kind of script (Starlark maybe?) that takes a command and set of qualifiers, and returns a command and set of qualifiers, building an appropriate command. The set of qualifiers returned should be the input minus any qualifiers handled by the script. We can chain such scripts together to build complex commands, while each qualifier is handled simply.

For example, operators could add a script that handles resource_type and pops out a command appropriate for the specified resource (e.g. a git command, a hg command, a curl command). Another script could take checksum.sri, and append a sha256sum of the downloaded resource. I think this might be the most sensible way to handle the feature of packing/unpacking resources also, instead of the "transparent unpacking" allowed by the spec -- a qualifier can be added to do it that adds a zip or unzip or tar command etc.

This will only help us for the remote execution backend, however. I think for the regular backends we could possibly add something like pre and post-fetch hooks to have some functionality like packing and unpacking, but have something like resource_type controlled entirely by what we actually have implemented. We should strongly encourage the use of the REAPI backend anyhow.