[WIP] Expand error handling support

[chrissimpkins]

This PR refactors existing custom errors to a new errors.rs module and replaces panics with error handling support across all source files.

WIP => Result return types were added across all functions that raise errors; however, I need input on how to work the error handling through the least_satisfying closures in:

cargo-bisect-rustc/src/main.rs

Lines 1249 to 1270 in 7ac0397

	let found = least_satisfying(&toolchains, |t| {
	match t.install(&client, &dl_spec) {
	Ok(()) => {
	let outcome = t.test(&cfg);
	// we want to fail, so a successful build doesn't satisfy us
	let r = match outcome {
	TestOutcome::Baseline => Satisfies::No,
	TestOutcome::Regressed => Satisfies::Yes,
	};
	if !cfg.args.preserve {
	let _ = t.remove(&dl_spec);
	}
	eprintln!("tested {}, got {}", t, r);
	r
	}
	Err(err) => {
	let _ = t.remove(&dl_spec);
	eprintln!("failed to install {}: {:?}", t, err);
	Satisfies::Unknown
	}
	}
	});

and

cargo-bisect-rustc/src/main.rs

Lines 1360 to 1383 in 7ac0397

	let found = least_satisfying(&toolchains, |t| {
	eprintln!("installing {}", t);
	match t.install(&client, &dl_spec) {
	Ok(()) => {
	eprintln!("testing {}", t);
	let outcome = t.test(&cfg);
	// we want to fail, so a successful build doesn't satisfy us
	let r = match outcome {
	TestOutcome::Regressed => Satisfies::Yes,
	TestOutcome::Baseline => Satisfies::No,
	};
	eprintln!("tested {}, got {}", t, r);
	if !cfg.args.preserve {
	let _ = t.remove(&dl_spec);
	}
	r
	}
	Err(err) => {
	let _ = t.remove(&dl_spec);
	eprintln!("failed to install {}: {:?}", t, err);
	Satisfies::Unknown
	}
	}
	});

At the moment, the errors raised in the Toolchain.test method will still panic during the least_satisfying tests.

Fixes #16
Supersedes #48

---

TODO

• eliminate panics in the least_satisfying part of bisect_nightlies
• eliminate panics in the least_satisfying part of bisect_ci_between

[chrissimpkins]

requires feedback

Is this a necessary error? I renamed it to make it a more general error type, but I think that it can be eliminated altogether?

[chrissimpkins]

need help here

Site of a TODO for least_satisfying function associated error handling

[chrissimpkins]

need help here

Site of a TODO for least_satisfying function associated error handling

[chrissimpkins]

requires feedback

The ExitError was in main and I simply renamed it to make it clear that this is the approach to explicitly define an exit status code number. It does not appear to be in use any longer. Maybe we just eliminate it?

[chrissimpkins]

Will rebase on the #57 merge if there is interest in this approach

[chrissimpkins]

Is there any interest in supporting this?