Cleaning up API surface before releasing 0.3.0

We're getting close to releasing 0.3.0. Are there any other papercuts on the API surface we want to clean up before release? Here are some ideas:

• MetadataPath and TargetPath own a String, but are mainly passed around as a reference. Should we instead replicate std::path::Path and use a dynamically sized type? Downside of this is that we'd have to use unsafe in order to construct these values.
• Should we create client::ClientBuilder and move the client::Config into it? Then people who just want the default wouldn't have to deal with passing around Config::default().
• The TUF spec refers to different formats as "POUFs". Should we rename tuf::interchange to tuf::pouf, and tuf::interchange::Json to tuf::pouf::Pouf1?
• Should we get rid of the HashAlgorithm enum, and use a dyn HashAlgorithm instead? That might allow better customization of the hash algorithm type.
• Should we drop support for the legacy hash_key_algorithm?
• The tuf::error::Error is a little messy. Is there a better way to clean it up?
• should tuf::verify::verify_signature be public?
• Change TargetsMetadata to store targets in a BTreeMap rather than a HashMap to make ordering stable.

Start by reviewing the listed API candidates: MetadataPath and TargetPath, client::Config, tuf::interchange, HashAlgorithm, tuf::error::Error, tuf::verify::verify_signature, and TargetsMetadata. Compare each proposal with the 0.3.0 release goals and the linked TUF and docs.rs references. Done requires a settled scope and decisions for the proposed API changes, not just an isolated edit.