Improve faulty compilation - unify handling of undeclared variables

[privat]

Note: This is another attempt on #12935.

Previously, running

{
OpalCompiler new evaluate: 'a := 1. a'.
OpalCompiler new evaluate: 'a'.
OpalCompiler new options: #(+optionSkipSemanticWarnings); evaluate: 'a := 2. a'.
OpalCompiler new options: #(+optionSkipSemanticWarnings); evaluate: 'a'.
}

gave #{1 1 nil nil} (and no exception or nothing).

That is not nice.

• bad: undefined variable have a weird semantic (see [Meta-issue] undeclared variables #13006 , this out of scope of the PR).
• worse: a random unrelated option of the compiler change the semantic.

I have no clue but if I try to guess "why?" such different behavior exists, I suppose it because optionSkipSemanticWarnings might be circumstantially used on frontend-only (parse for highlighting for instance) instead of on full compilation.
With optionSkipSemanticWarnings, undeclared variables are not registered, so do not fill the global Undeclared with garbage. (but maybe that's not the reason and I'm thinking too much)

Nevertheless, this is bad.
In the PR I propose to

1. unify the behavior (adding optionSkipSemanticWarnings does not change the compiled code)
2. undeclared variable are only registered if a compiled method is produced (by the backend), and again independently of random options.

Now

{
OpalCompiler new evaluate: 'a := 1. a'.
OpalCompiler new evaluate: 'a'.
OpalCompiler new options: #(+optionSkipSemanticWarnings); evaluate: 'a := 2. a'.
OpalCompiler new options: #(+optionSkipSemanticWarnings); evaluate: 'a'.
}

give #{1 1 2 2 }, it's still discutable but at least it is consistent (and memory efficient).

the PR will also help future and more aggressive PR by reducing the initial behavioral space.

[privat]

CI logs say #name:superclassName:traitComposition:classTraitComposition:category:instVarNames:classVarNames:poolDictionaryNames:classInstVarNames:type:comment:commentStamp: was sent to nil

yeah, I understand that nil was unprepared to receive such a message.

The question is more, how this PR can achieve that?

[privat]

I get it, the method called is MCClassDefinition class>>#name:superclassName:traitComposition:classTraitComposition:category:instVarNames:classVarNames:poolDictionaryNames:classInstVarNames:type:comment:commentStamp: (what a nice selector!) except that MCClassDefinition is still nil, therefore something is wrong. :(

[privat]

I hope I found the bug. I had to dig in the bootstrap and semi-blindly isolate faulty situations with handwritten .st files and inferring how damn those pesky ! interleaving method definitions with expressions in .st files works.

[privat]

Tests are ok minus a unrelated windows test