Expand "return condition" into "return condition ? true : false"

[EgorBo]

Closes #8363

Various control-flow related optimizations do not kick in for return <condition> patterns properly, because JIT mostly works with BBJ_COND types of blocks. optOptimizeBool is one of few phases which does support BBJ_RETURN but that support takes extra (a lot of) code to support.

Instead, let's just expand all return condition into return condition ? true : false and then convert back to return condition where profitable.

Example:

static bool Test(int x)
{
    return x == 10 || x == 20 || x == 30;
}

Here, "recognize bit-test" optimization (fgRecognizeSwitch) does not kick in due to BBJ_RETURN:

; Assembly listing for method Foo:Test(int):ubyte (FullOpts)
       cmp      ecx, 10
       je       SHORT G_M12679_IG04
       cmp      ecx, 20
       jne      SHORT G_M12679_IG06
G_M12679_IG04:
       mov      eax, 1
       ret      
G_M12679_IG06:
       cmp      ecx, 30
       sete     al
       movzx    rax, al
       ret      
; Total bytes of code 26

This PR:

; Assembly listing for method Foo:Test(int):ubyte (FullOpts)
       cmp      ecx, 30
       ja       SHORT G_M12679_IG06
       mov      eax, 0x3FEFFBFF
       bt       eax, ecx
       jb       SHORT G_M12679_IG06
       mov      eax, 1
       ret      
G_M12679_IG06:
       xor      eax, eax
       ret
; Total bytes of code 24

@stephentoub hit this problem when he was trying to showcase various jit optimizations on simple methods and had to rewrite them into if-else.

As a follow-up I might clean up various phases relying on BBJ_RETURN

[EgorBo]

@MihuBot

[EgorBo]

Will first address various size regressions in separate PRs before moving forward with this.

[xtqqczze]

@EgorBo Should this also close #65370?

[EgorBo]

@EgorBo Should this also close #65370?

thanks, indeed