`sway-fmt` formats all fields within a struct instantiation expression into a single line

[Braqzen]

The following example

contract;

use std::hash::*;

abi MyContract {
    fn test() -> bool;
}

struct SentinelTransaction {
    to: b256,
    value: b256,
    data: b256,
    executed: b256,
    approvals: b256,
}

storage {
    sentinel: SentinelTransaction,
}

impl MyContract for Contract {
    fn test() -> bool {
        storage.sentinel = SentinelTransaction {
            to: hash_u64(1, HashMethod::Sha256), 
            value: hash_u64(2, HashMethod::Sha256), 
            data: hash_u64(3, HashMethod::Sha256), 
            executed: hash_u64(4, HashMethod::Sha256), 
            approvals: hash_u64(5, HashMethod::Sha256)
        };
        true
    }
}

formats into

contract;

use std::hash::*;

abi MyContract {
    fn test() -> bool;
}

struct SentinelTransaction {
    to: b256,
    value: b256,
    data: b256,
    executed: b256,
    approvals: b256,
}

storage {
    sentinel: SentinelTransaction,
}

impl MyContract for Contract {
    fn test() -> bool {
        storage.sentinel = SentinelTransaction {
            to: hash_u64(1, HashMethod::Sha256), value: hash_u64(2, HashMethod::Sha256), data: hash_u64(3, HashMethod::Sha256), executed: hash_u64(4, HashMethod::Sha256), approvals: hash_u64(5, HashMethod::Sha256)
        };
        true
    }
}

Preferably it will remain the same as in the "before".

Related: #1210

[mitchmindtree]

@Braqzen if you want to draw attention to an issue feel free to cc @user, but do not assign others unless you've discussed it.

Having someone assigned to an issue means they plan to work on it imminently or have plans to solve it themselves. This is a useful indicator in the case that if someone else is considering picking up the issue, they can see whether or not someone else is already working on it. Folks will assign themselves to an issue when they start working on it.

Related #1425, cc @eureka-cpu

[adlerjohn]

@mitchmindtree that's on me as I wasn't clear in my instructions. @Braqzen assigning should indeed only be done by someone picking up the issue themselves, or with prior discussion on Slack.

The only exception to this is for triaging issues with an unknown root cause. Triaging here doesn't refer to "who will work on this issue" but rather "which team will work on this issue." E.g. you're not sure if the bug is in the compiler or the node. In this case, the issue is fairly unambiguously under the purview of the tooling team, and specifically the formatter, so no triaging is necessary.

[adlerjohn]

Labelling as enhancement since while the symptom is sub-optimal, it's from a missing feature rather than a bug.

[eureka-cpu]

The configuration file is almost ready over at #1425 and will make fixing this much easier @Braqzen if you'd like to tackle it once this PR gets through!