Add diagnostics to "while loop" and "for loop" that note that it is always determined that it migh t iterate zero times.

[Kohei316]

close #116572
When a user writes a loop expression as a tail expression, which has a loop header always executed, and which contains return expressions like this,

fn foo() -> bool {
    while let x = 0 {
        return true
    }
}

this,

fn foo() -> bool {
    while true {
        return true
    }
}

or this,

fn foo() -> bool {
    for i in 0..10 {
        return true
    }
}

they may be misundrestanding that it evaluate to not a unit type but un argument of the return expression.
This PR adds diagnositics which help clearing such misundrestanding.

[rustbot]

r? @nnethercote

rustbot has assigned @nnethercote.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[nnethercote]

A number of issues here.

• Error messages don't start with an upper-case letter, and don't end with a '.'.
• There is a lot of repetition here. The note and the following help both print the loop condition. The two could be merged. I am also not sure if the condition needs to be printed, given that the loop is printed above anyway.
• "It is determined" is too wordy, something like "this loop might iterate zero times" would be better.

But there are bigger concerns, which I will discuss below.

[nnethercote]

There's a big problem here: the error messages mentioned in #116572 have since changed greatly. E.g. for the first example in that issue it now just says "while loops evaluate to unit type ()" which I find sufficiently informative. In #116572 @Nadrieril wrote:

A workable solution would be instead to change the error message: the code that emits "this might have zero elements to iterate on" could check if the pattern is a single binding and emit a better error message if that's the case.

But because the message has changed so much, there is now no mention of zero elements, so this PR isn't following that suggestion.

#122561 was also complaining about the old message, and #123125 was the PR that changed the message in order to fix #122561. So I think this PR is not actually needed, and #116572 can now be closed. But I will ask Esteban, who reviewed #123125, for a second opinion, because this is a complicated situation and is stretching my expertise on error messages to breaking point.

r? @estebank