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.