IsImplicitlyDeclared for top-level statements

[Youssef1313]

When the feature was implemented initially, IsImplicitlyDeclared was set to be "true". Later on, it was changed in #44716 to return "false" to workaround IDE issues.

IsImplicitlyDeclared is a public API. Based on its documentation, consumers will expect true for <Main>$ and <Program>$.

I think it should be back to true again, and find another way to fix the IDE issues.

If an IDE feature is expected to work on top-level statements, and is currently depending on IsImplicitlyDeclared like:

if (!someSymbol.IsImplicitlyDeclared)
{
    // Allow feature to work.
}

Instead of making IsImplicitlyDeclared returns false, I think it's better to change the IDE feature to something like:

if (!someSymbol.IsImplicitlyDeclared || IsTopLevelStatement)
{
    // Allow feature to work.
}

Or: you can introduce a new property (CanContainUserCode).
For any symbol that has IsImplicitlyDeclared = false, CanContainUserCode must be true.
But if IsImplicitlyDeclared = true, then the value of CanContainUserCode depends.

Related to #48172 and #48171

cc: @CyrusNajmabadi @AlekseyTs

[AlekseyTs]

Saying that a compilation unit with top level statements explicitly declares containers of top level statements sounds reasonable to me.

[Youssef1313]

@AlekseyTs The concern here is the current behavior doesnt match the documentation.

[AlekseyTs]

I would be fine with updating documentation, if you think that would help. The current documentation is written sufficiently vaguely, it doesn't define what exactly constitutes an explicit declaration. Obviously, years ago we couldn't predict all the new features that we would add to the language. And that definition simply evolves as the language does.