New compiler: When in the body of a static struct function and finding an otherwise unknown symbol, imply static access

[fernewelten]

Fixes #2067

Currently, whenever the new compiler is compiling the body of a non-static struct function and it encounters an unknown identifier i in an expression, it doesn't give up yet. It looks up this.i first, and if that subexpression is valid, the compiler uses it.

This PR generalises this concept to static struct functions: When the compiler is compiling the body of a static struct function for the struct str and it encounters an unknown identifier i in an expression, it doesn't give up yet. It looks up str.i, and if that subexpression is valid, then the compiler uses it.

float FourCos(static Maths, float rd)
{
    return 4.0 * Cos(rd); // ← 'Cos' unknown, but 'Maths.Cos' exists so use that
}

This PR also fixes the following bugs:

• When a struct s extends another struct t and t has an attribute or a function af then this.af (or af when otherwise unknown) should reference t::af. This didn't always work but should work now.
• When a struct s has a non-static attribute a then calling s::a from a static function should fail because the specific object isn't known to which the attribute refers – only the class is known. This used to be flagged for functions but not for attributes. It should now also be flagged for attributes.

Added googletests for the new use cases and the bugs.

This PR also cleans up comments in the code (in a separate commit). No functional changes in that commit.

• Especially the comments at the start of the parser, which have partially become out of date by now.
• Sometimes comments preceded a function in the '.cpp' file where the same or a more accurate comment also was in the declaration of the '.h' header. In these cases I deleted the comment in the '.cpp' file to prevent contradictions or mismatches.