create src/errors.rs with generic errors for the entire crate

[dlaehnemann]

In PR #165 (now superseded by PR #214 ), the review led to the idea of defining generic errors like FileNotFound and NonUnicodePath on the highest level of the crate, i.e. in a new file src/errors.rs. This avoids redundantly defining such errors for all submodules. Currently, the two example errors are defined both for bam, tbx and faidx:

rust-htslib/src/bam/errors.rs

Lines 21 to 24 in 61b0644

	#[snafu(display("file not found: {}", path.display()))]
	FileNotFound { path: PathBuf },
	#[snafu(display("invalid (non-unique) characters in path"))]
	NonUnicodePath,

rust-htslib/src/tbx/errors.rs

Lines 15 to 18 in 61b0644

	#[snafu(display("file not found: {}", path.display()))]
	FileNotFound { path: PathBuf },
	#[snafu(display("invalid (non-unique) characters in path"))]
	NonUnicodePath,

rust-htslib/src/faidx/errors.rs

Lines 9 to 12 in 29565f9

	#[snafu(display("file not found: {}", path.display()))]
	FileNotFound { path: PathBuf },
	#[snafu(display("invalid (non-unicode) characters in path"))]
	NonUnicodePath,

And NonUnicodePath is also defined for bcf, but FileNotFound is missing there. So such high-level definition could also help clean up the errors a bit:

rust-htslib/src/bcf/errors.rs

Lines 40 to 41 in 61b0644

	#[snafu(display("invalid (non-unique) characters in path"))]
	NonUnicodePath,

[dlaehnemann]

While this change happens, we could also think about moving the path_as_bytes function up to src/utils.rs:

rust-htslib/src/faidx/mod.rs

Lines 19 to 32 in 29565f9

	fn path_as_bytes<'a, P: 'a + AsRef<Path>>(path: P, must_exist: bool) -> Result<Vec<u8>> {
	if path.as_ref().exists() || !must_exist {
	Ok(path
	.as_ref()
	.to_str()
	.ok_or(Error::NonUnicodePath)?
	.as_bytes()
	.to_owned())
	} else {
	Err(Error::FileNotFound {
	path: path.as_ref().to_owned(),
	})
	}
	}

[landesfeind]

As discussed, I started working on this. First draft is available in landesfeind/rust-htslib:215_generic_errors_for_entire_crate

While there are clearly some generic errors, others are also quite specific to the modules. I am wondering if there is a preference in using specialized errors with a prefix (i.e., what I did in a first merge to solve name-conflicts) like BcfSeek or if we should try to harmonize/generalize them (e.g., GenomicSeek { target: String, position: u64 } versus FileSeek)

Any thoughts?