Track conditionally assigned variables by condition

[Pilchie]

Version Used:
3.0.0-beta2-18616-01

Steps to Reproduce:

class C
{
    object? F()
    {
        bool b = true;
        object? o = b ? new object() : null;

        return b ? F(o) : null;
    }

    object F(object o) { return o; }

}

Expected Behavior:
No warning

Actual Behavior:
UnitTest1.cs(8,22,8,23): warning CS8604: Possible null reference argument for parameter 'o' in 'object C.F(object o)'.

[gafter]

We don't track the values of variables, and that is unlikely to be added to the scope of this NRT feature.

[AartBluestoke]

I was raising an issue but found it to be duplicate of this issue while writing it: "It should not be an error (or null warning) to use a conditionally assigned variable under the same condition it was assigned"

I'm unsure if the variant of this relating to use of unassigned variables is the same or different, so i'll post here to avoid cluttering issues.

Version Used:
gist: master 12th april 2019 / also on default (2.9.0)
Steps to Reproduce:
attempt to compile

using System;
public class C {
    readonly bool doLog = true;

    public void M() {
        //bool doLog = true; //also fails if doLog is a local var.
        string s;  
        if(doLog)
            s="some calculated thing only relevant when logging is present";
        //later ...  or even straight away
        if(doLog)
            Console.WriteLine(s);
    }
}

Expected Behavior:
when the 2 conditions are identical, and the bool is not mentioned inbetween / never modified, that the code compiles.

Actual Behavior:
error CS0165: Use of unassigned local variable 's' in writeline

---

As a side note, i started from an unexpected "this could be null" warning with nullability enabled, which was similar to #31893, but i only found that ticket after simplifying down to the 'unassigned use' example found here

#31893, has the comment of "we don't trace values" however:

The following code does compile, so the compiler is capable of understanding that both the true and false branches of the code produce sensible outcomes :
https://sharplab.io/#gist:6826ab703a954013f7844a5e614a3dd5

using System;
public class C {
    public void M() {
        const bool trueThing = true;
        string trueString;  
        if(trueThing)
            trueString="some calculated thing only relevant when logging is present";
        //later ...  or even straight away
        if(trueThing)
            Console.WriteLine(trueString);

        const bool falseThing = false;
         string falseString;  
        if(falseThing)
            falseString="some calculated thing only relevant when logging is present";
        //later ...  or even straight away
        if(falseThing)
            Console.WriteLine(falseString);        
    }
}

[AartBluestoke]

this doesn't have to do value tracking; it only needs to determine that access and assignment are guarded by the same condition.

[gafter]

This is a language feature request, so belongs in csharplang. We are tracking it at dotnet/csharplang#2388 .