enable updating signature collections

[bluegenes]

moving from #1365

@bluegenes:
With picklists and now manifests on the horizon, we should be able to update collections: read the manifest, and only sketch signatures if they do not already exist.

I think this would involve building the manifest row for a signature that would be generated, checking the existing manifest, and then sketching + adding to the collection if needed. I know this doesn't save a lot of time for a couple signatures, but could save a lot for large collections. Would love to hear thoughts about the downsides of enabling this, though!

My thinking = now that we can extract specific signatures using picklists, folks can keep all their query signatures together in a single (or multiple) zipfile collections, if they want! If this is the case, you can imagine that sometimes folks (me) want to add an additional sample or ksize without needing to regenerate the entire collection.

@ctb
this is an interesting idea, and actually a pretty good use case for IPFS and Redis storage backends, too - people wouldn't need to track filenames if their personal collection of signatures was just floating around in a database namespace somewhere.

Minor note - only a subset of the signature metadata would apply - identifier, moltype, ksize, and filename, I think.

[ctb]

#1885 fixes this.

Note that zip files already support addition of signatures natively, with -o.