Merge some lints together

[mcarton]

Clippy has a lot of lints now, but sometimes there is not much difference between two lints. I think we should merge some of them together.

Advantages

• Slightly shorter big-list-of-all-the-lints.
• Less documentation duplication (see new_without_default and new_without_default_derive).
• Two lints should be different only when one would want to set different allow/warn/deny level for them. Why would anyone ever want to forbid calls to Option::unwrap but not Result::unwrap?
• Less confusing as to why there are two different lints for that.

Disadvantages

• Might be a breaking change, but IIRC rustc has a way to indicate a lint was renamed (and hopefully handle properly #[allow]s etc. on it).
• Need to find new names.

Candidates

Here are some candidates (there might be other):

• block_in_if_condition_expr and block_in_if_condition_stmt → rename them both to block_in_if_condition;
• option_map_unwrap_or and option_map_unwrap_or_else → option_map_unwrap;
• result_unwrap_used and option_unwrap_used → unwrap_used;
• for_loop_over_option and for_loop_over_result → ?
• new_without_default and new_without_default_derive → new_without_default (the only difference is how the suggestion is built);
• string_add and string_add_assign → string_add;
• identity_op and modulo_one → useless_arithmetic

[Manishearth]

Bit iffy on string_add, but otherwise LGTM.

Perhaps this should be tabled till the RfC at https://github.com/Manishearth/rust-clippy/issues/533? I'm thinking of starting the RfC this week or so, so add more issues to that thread if you find them.

[mcarton]

Bit iffy on string_add, but otherwise LGTM.

There already is assign_op_pattern vs. assign_ops for the + vs. += difference (and those really are different, they should not be merged), so keeping the distinction between those just for the String case seems redundant IMO.

[Manishearth]

I guess so.