Add new lint map_or_same_constant

[ivanlomeli]

Summary

This PR adds a new lint map_or_same_constant in the suspicious category.
It warns when Option::map_or, Result::map_or, or their map_or_else variants use the same constant result for both branches (e.g. opt.map_or(false, |_| false) or opt.map_or_else(|| 0, |_| 0)).

closes #17544

---

changelog: [map_or_same_constant]: Add new lint to check for map_or / map_or_else where both branches return the same constant value

[rustbot]

Thanks for the pull request, and welcome!

You should hear from one of our reviewers after this PR gets at least 2 reviews from the community.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[rustbot]

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 3016cfa

[rustbot]

☔ The latest upstream changes (possibly #17537) made this pull request unmergeable. Please resolve the merge conflicts.

[CommanderStorm]

Code wise mostly LGTM, but there is some missing test coverage for the cases you covered 😉

The actual thing that we need to work out clearer it seems is how it interacts with unnecessary_map_or.

View changes since this review

[CommanderStorm]

Looking of the code, all of them are covered.
could you add testcases for map_or/map_or_else being:

• macros + proc macro
• constant, but including an side effect like black_box
• map_or not being the Option::map_or, but coming from an trait/impl

[CommanderStorm]

Could you expect instead of allow instead?

Also, when do they overlap, can we improve this?
Ideally, the same code should not lint twice, since that sounds like a source for confusion, or?