Suggest changing `result.map_or_else(|error| Err(whatever(error)), Ok)` to `result.map_err(whatever)`

What it does

While refactoring a project of mine, I found that I did something weird:
https://github.com/conqp/ansi-color-codec/commit/f5b90aea8da2f680f4a595ac508102ab267cba5b
However, though running clippy in pedantic mode, it did not nag about me using map_or_else() where I just could have used map_err(). Maybe this is worth a new lint.

Advantage

• Arguably more idiomatic use of Result's mapping functions
• More concise code

Drawbacks

• None

Example

    fn read_color_code(&mut self) -> Result<u8, Error> {
        let digits = self.read_digits()?;
        self.bytes.next(); // Discard bg-color encoded char
        digits
            .parse::<u8>()
            .map_or_else(|error| Err(Error::InvalidCodeValue(error)), Ok)
    }

Could be written as:

    fn read_color_code(&mut self) -> Result<u8, Error> {
        let digits = self.read_digits()?;
        self.bytes.next(); // Discard bg-color encoded char
        digits.parse::<u8>().map_err(Error::InvalidCodeValue)
    }

Start by reviewing the Rust examples in the issue and Clippy's existing lint patterns for analogous Result transformations. The work is done when a lint detects the map_or_else(|error| Err(whatever(error)), Ok) form and recommends the equivalent map_err(whatever) form without flagging unrelated code.