Adjust assert to account for error scenarios

[RikkiGibson]

Related to #66046

The effect of a constructor initializer is to prepend a statement to the effect of

S..ctor()
{
    S..otherCtor(out this, ...);
    // ... original constructor body statements
}

The point of this assert is that if a constructor initializer is present, it doesn't make sense for implicitly initialized fields to also be present, since you cannot access this until after the constructor initializer runs, which fully assigns this.

In error scenarios we can still end up referencing instance fields before the constructor initializer, so we relax the assert to allow the "unexpected" implicit initializations in this case.

Auto-default logic runs simply as a part of definite assignment analysis, so I think there is not a ton to be gained by skipping it when a constructor initializer is present. We could consider avoiding adding to the implicitlyInitializedFields when we notice a constructor initializer is present, but IMO this isn't necessary, and it's a little simpler to just adjust this assert to reflect our expectations. I'm open to discussion on this point, though.

In the future, if this assert fails, it means we are using an unassigned field before the constructor initializer has run in code without errors.

@AlekseyTs @dotnet/roslyn-compiler for review.

[jcouv]

nit: consider linking to issue

[jcouv]

LGTM Thanks (iteration 1)

[AlekseyTs]

@RikkiGibson As I mentioned in #66046: "Please keep the issue active until that assert is re-enabled." That is in the feature branch.

[RikkiGibson]

@AlekseyTs Let me know if the adjusted assert seems reasonable to you. Thanks

[AlekseyTs]

LGTM (commit 3)

[AlekseyTs]

@RikkiGibson Please assign the issue to me once you merge