[CLI] Deduplicate optimizer initialization

[cameel]

Related to #11720.
Also implements part of #11629.

There were multiple places that initialized OptimiserSettings: it's needed for validation in CommandLineParser and later in CommandLineInterface to actually initialize the compiler. In both cases the initialization was performed separately for the compiler and for the assembler. Now there's a single function that creates the struct based on CommandLineOptions.

This change would result in optimizer settings being parsed (but unused) in linker mode so I also made the compiler reject them in this mode and also in Standard JSON mode.

[cameel]

Note that this line was not in assemble(), only in compile(). I removed it because it's redundant anyway. With current defaults in OptimierSettings the value of optimizeStackAllocation always matches runYulOptimiser. On the CLI they can only be different if you use --no-optimize-yul and that option is invalid in assembly mode.

[ekpyron]

Looks fine apart from maybe the changelog entry.

Although (I keep saying this), I still think it's a waste of time and energy meddling with this infernal command line interface instead of replacing it by a translation layer to StandardCompiler right away :-).

[cameel]

Although (I keep saying this), I still think it's a waste of time and energy meddling with this infernal command line interface instead of replacing it by a translation layer to StandardCompiler right away :-).

But we won't be throwing out CommandLineParser completely, will we? It's completely CLI-specific and half of this change touches the code there. The other half deals with converting optimizer options to OptimiserSettings - that part would be gone but instead we'd have to convert them to Standard JSON input. So this refactor would make sense even after such a rewrite.

Also, I went though CommandLineInterface to see how much would be rewritten and a lot of it deals with formatting the CLI output. Input parsing was also a large part of it but that's now in CommandLineParser. The part that would actually have to be rewritten on top of Standard JSON is in just 3 functions: compile(), handleAst() and assemble(). That's ~250 lines out of more than 1000 (+ another 1000 in CommandLineParser). I think that extracting output formatting into a separate component, like I did with CommandLineParser would actually make more sense. Then we could rewrite or improve each part separately instead of having a monster task to rewrite everything.

[ekpyron]

Although (I keep saying this), I still think it's a waste of time and energy meddling with this infernal command line interface instead of replacing it by a translation layer to StandardCompiler right away :-).

But we won't be throwing out CommandLineParser completely, will we? It's completely CLI-specific and half of this change touches the code there. The other half deals with converting optimizer options to OptimiserSettings - that part would be gone but instead we'd have to convert them to Standard JSON input. So this refactor would make sense even after such a rewrite.

Also, I went though CommandLineInterface to see how much would be rewritten and a lot of it deals with formatting the CLI output. Input parsing was also a large part of it but that's now in CommandLineParser. The part that would actually have to be rewritten on top of Standard JSON is in just 3 functions: compile(), handleAst() and assemble(). That's ~250 lines out of more than 1000 (+ another 1000 in CommandLineParser). I think that extracting output formatting into a separate component, like I did with CommandLineParser would actually make more sense. Then we could rewrite or improve each part separately instead of having a monster task to rewrite everything.

Well ok, fair enough - you may be right that that may in fact be the best way to achieve the same thing.