[1/x] Add Wasm component translation support to the integration tests

[greenhat]

Add Wasm component translation support to CompileTest.
Add a text representation of the IR Component and use it in the expected tests.

[greenhat]

@bitwalker I'd like Component to have a textual representation for expected tests. I'm thinking of putting module's body in curly braces (+indent) and printing them sequentially. Plus, I'd like to print Component imports as well. So far I drafted them like https://github.com/0xPolygonMiden/compiler/blob/72bf0d30e69f856e2313ff8f9e5701dfc359e372/tests/integration/expected/components/inc_wasm_component.hir#L3 .
What do you think?

[bitwalker]

I'm thinking of putting module's body in curly braces (+indent) and printing them sequentially

I think that should be fine. One thing I'm considering is whether or not to switch to an s-expr representation like Wasm, to make it easier to maintain and extend, and to keep the parser dead simple - but until that happens, I think this is likely to be the only unambiguous way to represent components in the textual format.

Plus, I'd like to print Component imports as well. So far I drafted them like

I think we should use attributes for metadata items like the "call" annotation (which I think should specify a calling convention, rather than something one off, since call and exec will have different calling conventions, and call will have only one possible calling convention), as well as the MAST root. Otherwise I think that looks fine. We may have to support quoted identifiers so that those used for component imports/exports are more unambiguous, but I'll have to confirm whether or not it is actually an issue.

[greenhat]

I'm thinking of putting module's body in curly braces (+indent) and printing them sequentially

I think that should be fine. One thing I'm considering is whether or not to switch to an s-expr representation like Wasm, to make it easier to maintain and extend, and to keep the parser dead simple - but until that happens, I think this is likely to be the only unambiguous way to represent components in the textual format.

I got back to this PR to add curly braces, and I don't know why I have not replied to this earlier, but I like the s-expr idea very much. Admittedly, after staring into WAT for so long, I find it very readable.

[bitwalker]

@greenhat I think we'll want to reimplement these changes on #149 since we'll need to port the changes over anyway. Since the PR updates all of the tests, all that is really needed are the new IR components, implementing the formatting using PrettyPrint rather than Display, and adding the new grammar rule for components. If you like, I can do that for you, since I can probably do the refactoring faster due to familiarity, but I'll leave it up to you.

In any case, PR looks good otherwise, so if you are cool with me refactoring it for you, I'll go ahead and do that

[greenhat]

@greenhat I think we'll want to reimplement these changes on #149 since we'll need to port the changes over anyway. Since the PR updates all of the tests, all that is really needed are the new IR components, implementing the formatting using PrettyPrint rather than Display, and adding the new grammar rule for components. If you like, I can do that for you, since I can probably do the refactoring faster due to familiarity, but I'll leave it up to you.

In any case, PR looks good otherwise, so if you are cool with me refactoring it for you, I'll go ahead and do that

Sure. I appreciate it if you'd take care of that. Thanks.