fix: print slice composite types surrounded by parentheses

[asterite]

Description

Problem

Resolves #8408

Summary

Let me know if composite types shouldn't be surrounded by parentheses. It's something I already did for arrays a long time ago (when writing the SSA parser, or maybe even before that).

Additional Context

I can't remember why I added those parentheses, it was maybe for clarity or to avoid an ambiguity.

Then I just tried to generate SSA for this code:

fn main() {
    let _ = [(); 4];
}

The result is:

acir(inline) fn main f0 {
  b0():
    v0 = make_array [] : [(); 4]
    return
}

I guess without those () it would look like [; 4] so we'd have to assume, when parsing, that if no type comes it's an empty list... but maybe that makes it harder to distinguish between that and a mistake.

I think back when I implemented the SSA parser I wasn't sure what all types were, so when parsing parameters b0: Field, b1: Field, if we allowed composite types in the parameters it would be harder to parse because we see Field, ... and we don't know if another type comes. Well, composite types aren't allowed in parameters, but in the end using parentheses is maybe clearer and more consistent.

Documentation

Check one:

• No documentation needed.
• Documentation included in this PR.
• [For Experimental Features] Documentation to be submitted in a separate PR.

PR Checklist

• I have tested the changes locally.
• I have formatted the changes with Prettier and/or cargo fmt on default settings.

[vezenovm]

if we allowed composite types in the parameters it would be harder to parse because we see Field, ... and we don't know if another type comes. Well, composite types aren't allowed in parameters, but in the end using parentheses is maybe clearer and more consistent.

We do allow composite types in parameters they just will be flattened to separate variables as you have outlined.

[vezenovm]

I find the parentheses clearer and it aligns with what we do for arrays. Thanks!