Add dict literal syntax

[bloodyowl]

This PR adds basic support for the dict{} literal syntax (#6545).

Parsing

Semantics within the braces are similar to the record with string keys (as dict keys can be any string).

It then turns dict{"foo": "bar"} into Js.Dict.fromArray([("foo", "bar")]).

Printing

Any Js.Dict.fromArray call that contains a literal array of tuples (with no spread) is now printed as dict{...}.

I think this change is safe for the upcoming stdlib change (that'll move Js.Dict into Dict) as the change will be invisible once using this syntax. If that's something we don't want, we can add an attribute when parsing a dict{} expression so that we only print those back and leave Js.Dict.fromArray calls.

[IwanKaramazow]

Can you add a changelog entry?

[cknitt]

Could you remove the unrelated changes in belt_HashSetString.resi and belt_HashSetInt.resi?

[zth]

If that's something we don't want, we can add an attribute when parsing a dict{} expression so that we only print those back and leave Js.Dict.fromArray calls.

An attribute somehow might actually be beneficial for the editor tooling, if we want to do typed completion for values for instance.

[bloodyowl]

@zth aren't the rules the same as (Js.)Dict.fromArray? couldn't we generalize autocompletion here?

[IwanKaramazow]

I'm also curious for the use case of the editor tooling =D Wouldn't we want to upgrade codebases automatically through the formatter?

[JonoPrest]

Just noting #6617 supports spread syntax if you want to vendor anything across.

[cknitt]

@bloodyowl What's the status of this PR? Would be great to get this feature merged!

[hiovi]

Yes, I agree. This would be a cool feature to have.

[aspeddro]

Related #6836

@cknitt I think this needs to be adapted, right?

[cknitt]

Right, but this can be done independently later.

[cknitt]

@zth Rebased