Triage the list of allowed lints, addressing most of them.

[eddyb]

In no particular order, these are the suspicious and/or not-entirely-addressed lints:

• clippy::single_match_else: permanently #![allow(…)]ed, as the style it denies is important for readability
• clippy::string_add: permanently #![allow(…)]ed, as it's (IMO) misguided (and perhaps buggy?)
  • (...: String) + "..." is short for { let mut s = ...; s.push_str("..."); s }, not something else
• clippy::match_same_arms: #[allow(…)] moved to specific matches where listing out the patterns individually is more important than what the actual values are (i.e. grouping by the output values is detrimental)
• clippy::should_implement_trait: #![allow(…)] moved to specific module encountering this bug:
  • should_implement_trait triggers for next() where the return value has lifetimes rust-lang/rust-clippy#5004
• clippy::unused_self: #[allow(…)] moved to specific impl (where self may be used in the future)
• clippy::redundant_closure_call: #[allow(…)] moved to specific macro using a closure as a try {...} block
• clippy::map_err_ignore: had to be worked around because the map_err(|_| it complains about have no information in the error, i.e. those Results might as well be a newtyped Option
• clippy::nonminimal_bool: had to be worked around by introducing extra ifs (which should make the logic clearer)
  • long-term, nonminimal_bool could be a real hazard, if it suggests e.g. rewriting !(foo && foo_bar) into !foo || !foo_bar, when the point of the && is to group a foo_bar check with its foo prerequisite
    _{(in fact, I need to comb through Rust-GPU looking for artifacts of this lint, because I've seen in the past conditions that were rendered unreadable by an outer ! being De Morgan'd into a &&, where the outer ! may have just been coincidental from e.g. a retain/filter predicate's keep/remove distinction, but with || the correlation between the two sides was erased...)}

Fixes #13

cc @Jake-Shadle (this arguably counts as feedback for Embark's list of lints)