consider using sourmash core ComputeParameters instead of BuildParams

[bluegenes]

With #112, BuildParams gets closer to sourmash::cmd::ComputeParameters.

Differences:

• ComputeParameters have multiple ksizes, which makes them non 1:1 with records.
  • I suppose i could just implement a from_param_str that builds computeparams with single ksizes, which then would be a 1:1 drop-in.
• BuildParams uses the HashFunctions enum when reading in a command line parameter string. Not necessary, but kinda nice.

[bluegenes]

Actually, I think the main barrier right now is the sig filtering strategy. Currently, we store a hashed version of the BuildParams in the template Record. I then use that to filter out any BuildParams that we find in already-generated sketches.

Change filter to use an intersect_manifest approach (but inverse, keeping any non-matches), I think we could use the ComputeParameters without issue -- we would just iterate across ksizes while creating the template signatures + records in BuildCollection, which we already have to do anyway.

potential strategy:

• when reading existing records, store HashMap of name: mini manifest to avoid iterating through the entire manifest for each signature name?
• implement intersect_manifest for BuildManifest and BuildCollection
• I think this would need a PartialEq between BuildRecord and standard Record that only checks a subset of params (e.g. ksize, scaled, NOT md5sum)

[bluegenes]

This is in progress in #127