fix!: several format string fixes and improvements

[asterite]

Description

Problem

Resolves #4642

Summary

This PR includes several fixes and improvements to format strings:

1. Format strings (f"..."), as tokens, are now represented as fragments which can either be strings or interpolated pieces. The interpolated pieces also have a Span to know where they are. The advantage of this is that we don't need to use a regex to find the interpolations and we can provide better error messages when, for example, the interpolated variable doesn't exist. That said, the print oracle gets the raw string and needs to do the interpolation, and that still uses regex (but at least compile-time code won't need to do regex matching each time it finds a fmtstr).
2. We now disallow non-identifiers in interpolations. This actually uncovered a few "bugs" in the standard library where we were using interpolations in a wrong way.
3. Escape sequences like \n and \t are now allowed inside format strings.
4. We also now allow escaping { and } and we do that just like in Rust: {{ to mean {, }} to mean }.
5. Like in Rust, if you write } but there was no single { before it (we were not in an interpolation) you get an error that says you must use }} to write }.

Because {{ now means to write {, I had to slightly change the print oracle to understand this.

Additional Context

I'm marking this PR as a breaking change because it could break someone's code if they had incorrect interpolations, or if they had \n inside a format string and wanted to actually print "\" and "n" separately.

I left LSP features as a follow-up PR, mainly because I realized autocompletion doesn't automatically kick in when you are typing inside a string literal, so implementing completion there doesn't seem very useful. What we could do is at least implement "hover" in these pieces (go-to-definition already works).

A question: do print oracles exist somewhere else? For example in a web context (what I'm saying might not make sense, sorry). I'm just wondering if the print oracle logic of handling interpolations must be updated somewhere else too.

Documentation

This PR might need to document format string escape sequences... but I couldn't find this explained for strings so maybe all of that could be done in one go in a separate PR (if really needed now).

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.

[jfecher]

However, if you write f"{foo.bar}" then I think that should error but it doesn't (you get "{foo.bar}" printed) so given that we don't handle such errors I didn't want to handle any error at all.

We should definitely error here eventually, it's quite an annoyance while writing format strings

[asterite]

Awesome! I'll tackle that next, it should be relatively easy to do.

I also noticed that if you write f"Hello {x}" and x gives an error (say, it doesn't exist) then the error is on the entire format string. I'll try to improve that too (in yet another PR).

[github-actions]

Peak Memory Sample

Program	Peak Memory	%
keccak256	81.50M	0%
workspace	121.95M	-1%
regression_4709	333.71M	0%
ram_blowup_regression	2.55G	0%

[asterite]

Oooh... a test is failing because it has this:

        let s1 = f"x is {x}, fake interpolation: \{y}, y is {y}";

I guess \{ was used to escape that { (though that \ is still printed). In Rust to do that you write {{. Which way do we want to use?

[jfecher]

Let's stick with Rust in this case

[aakoshh]

LGTM 👍

[github-actions]

Changes to Brillig bytecode sizes

Generated at commit: 0d357023f20128a5e906f14121c0b72b34fc1175, compared to commit: 5ccde8196400a9b99e5c3c4d9af0e3136e72b4cb

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
uhashmap	+26 ❌	+0.18%
hashmap	+34 ❌	+0.16%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
uhashmap	14,178 (+26)	+0.18%
hashmap	21,899 (+34)	+0.16%

[github-actions]

Changes to number of Brillig opcodes executed

Generated at commit: 0d357023f20128a5e906f14121c0b72b34fc1175, compared to commit: 5ccde8196400a9b99e5c3c4d9af0e3136e72b4cb

🧾 Summary (10% most significant diffs)

Program	Brillig opcodes (+/-)	%
hashmap	-20 ✅	-0.04%
uhashmap	-348 ✅	-0.24%

---

Full diff report 👇

Program	Brillig opcodes (+/-)	%
hashmap	55,540 (-20)	-0.04%
uhashmap	146,948 (-348)	-0.24%

[asterite]

Asking for a re-review because this PR now does a lot more than what I originally planned.

[aakoshh]

Looks good!