Simplify BindingsMap by instead relying on StaticModuleScope for atom type resolution

[radeusgd]

Pull Request Description

• Removing AtomTypeInterface - it was a useful temporary hack, but in the longer term it seemed to not really solve the problem we had.
• Now storing the types of atom constructor arguments in StaticModuleScope, so I can remove the Expression from BindingsMap. I think that storing IR inside of metadata attached to said IR (which was the reason for introducing cycles) was a bad idea after all.
• Thus, the TypeRepresentation is greatly simplified - it no longer refences complicated objects like AtomTypeInterface (which had a nice API but ugly internals, and the internals were affecting serialization). Now TypeRepresentation becomes just plain data, a much simpler representation and I think it is closer to what it was supposed to be from the beginning.

Important Notes

Checklist

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

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  TypeScript,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• Unit tests have been written where possible.
• If meaningful changes were made to logic or tests affecting Enso Cloud integration in the libraries,
  or the Snowflake database integration, a run of the Extra Tests has been scheduled.
  • If applicable, it is suggested to paste a link to a successful run of the Extra Tests.

[radeusgd]

This removes the infamous cycle from the IR - the Expression holding the type of the constructor is no longer needed.

That's because we process this type Expression in StaticModuleScopeAnalysis and save it in StaticModuleScope metadata as an already processed TypeRepresentation - so it is no longer IR that is stored inside of metadata, but a simpler data structure representing our types.

[radeusgd]

This is mostly moved from the TypeResolver.

[radeusgd]

Our type representation is no longer holding references to some complex AtomTypeInterface structure which internally was holding references to BindingsMap and was overall ugly.

Now the TypeRepresentation is a plain data type. The information about Atom type interface is instead encoded in the StaticModuleScope, like information about method already has been.

[radeusgd]

@JaroslavTulach shall we maybe disable the support for cycles in IR persistence now?

I think we are no longer relying on it and there were issues with it from time to time so maybe we should change the code to fail on cycles and keep an eye on us accidentally re-introducing these problematic cycles?

btw. I think the cycles could have been also why @Akirathan could not use equality for comparing IR and had to resort to identity. I'm not sure if we had any other cycles than this one? If not, maybe we could try to come back to equality over identity then.