Removal of useless ApplicationSaturation phase

[JaroslavTulach]

Pull Request Description

Work on #8172 has revealed that ApplicationSaturation phase of the IR compiler is kind of special. It pre-executes saturated applications help the compiler replace code with constants. While such IR compiler pass may be needed in a static compilation, it is very likely useless in dynamicaly compiled language like Enso. Let's verify it by removing the pass and checking effect of such change on benchmarks.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• All code follows the
  Scala,
  Java,
• All code has been tested:
  • Remaining unit tests passing
  • Benchmark results remain unchanged

[JaroslavTulach]

Benchmark runs:

• engine benchmarks - seems OK, but one more run scheduled to confirm that
• stdlib benchmarks - the stdlib benchmarks are clearly OK

[radeusgd]

Was the ApplicationSaturation pass ever actually used outside of tests??

Looking at this initializer, we can see that the Configuration gets initialized with an empty Map for knownFunctions. And if the encountered funtion is not one of knownFunctions, it seems to always get the Unknown state, not influencing the codegen in any way.

I also don't see any other place where this pass is configured to "know" any functions and be able to do anything useful.

So I suspect we shouldn't see any difference in benchmarks, because we seem to be removing already practically unused code.

[radeusgd]

Looking at usages of the FunctionSpec, I cannot see anywhere in the codebase where it is constructed with the codegenHelper different than dummyFn (which does not do anything). So I really suspect this pass was never really fully used.

[Akirathan]

Unused compiler pass? I had no idea we even had ApplicationSaturation. Good observation.

[JaroslavTulach]

Benchmark runs:

* [engine benchmarks](https://github.com/enso-org/enso/actions/runs/6693072844) - seems OK, but [one more run](https://github.com/enso-org/enso/actions/runs/6695465210) scheduled to confirm that

* [stdlib benchmarks](https://github.com/enso-org/enso/actions/runs/6693078083) - the _stdlib benchmarks_ are clearly OK

Benchmarks seem to be unaffected. Merging.

[JaroslavTulach]

A note by @kustosz:

Application saturation was an optimization pass that turned out to not actually optimize anything
So removing it is good