Use match_function_call wherever possible

[Lythenas]

Move match_function_call to utils and use it wherever possible as discussed in #4635.

changelog: none

[Lythenas]

I wasn't able to use match_function_call everywhere.

• clippy_lints/src/explicit_write.rs:44 is a little more inefficient than before because it matches ExprKind::Call twice now.
• For a couple other places something that only matches the ExprKind::Path could be used.
• For some other places something a little more generic would be better. E.g. fn match_function_call_map(cx, expr, cb: Fn(&[&str], &[Expr]) -> b) -> Option<b> would be better. E.g. at clippy_lints/src/explicit_write.rs:44 we could match the path in the callback

But then there might be to many util function that do almost the same thing. Maybe just one generalized version of match_function_call would be better. But I'm not sure how that would look. And to be honest I think it's ok the way it is now.

Also what should I put in changelog?

[phansch]

@bors r+ thanks!

too many util functions that do almost the same thing

I think that's fine as long as they are all documented. They could possibly be split up into separate modules if it gets too confusing? (In general I don't like the notion of utils but I think it's fine for now)

Also what should I put in changelog?

changelog: none is fine for refactorings; it's only meant for user-facing changes that are listed in the changelog

[bors]

📌 Commit 15b433a has been approved by phansch

[bors]

⌛ Testing commit 15b433a with merge 9ee6eb1...

[bors]

💔 Test failed - status-appveyor

[phansch]

@bors retry

[bors]

⌛ Testing commit 15b433a with merge a865d0a...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: phansch
Pushing a865d0a to master...