chore: improve interpolation documentation by making it an syntax-enum

[CommanderStorm]

This PR documents how interpolations work in a more structured way.

I am not sure if my docs are too verbose, I tried to be fairly precisce since cutting is mostly simpler.

[github-actions]

Size Change: +346 B (+0.26%)

Total Size: 135 kB

Filename	Size	Change
dist/index.cjs	68 kB	+175 B (+0.26%)
dist/index.mjs	67 kB	+171 B (+0.26%)

_{compressed-size-action}

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.73%. Comparing base (c422581) to head (87c0da0).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1400   +/-   ##
=======================================
  Coverage   93.73%   93.73%           
=======================================
  Files         111      111           
  Lines        4626     4626           
  Branches     1557     1557           
=======================================
  Hits         4336     4336           
  Misses        290      290           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[HarelM]

Is there a different way to achieve this? I prefer to be as generic as possible here...

[CommanderStorm]

The other "length1-array with syntax-enum as value" is expressions.
Expressions are manually codegen-ed, so there is no code to reuse.

Also, the indentation and newline requirement (those two spaces before \n) would be a bit tricky to do this way.

Unless you want a major change to how this system works (which might make sense, but would be a larger change)

[HarelM]

In saying the same thing in both comments basically: is there a more generalized way to achieve the same thing? Or maybe reuse some code?
At the very least, since this is specific, it should be extracted to a method.

[CommanderStorm]

Generalised? Not without basically rewriting the entire thing.
This is one of the core parts and the impact of this is likely larger.
I don't think that reusing code is possible.

I moved the two things you commented on to a function each.

[HarelM]

I think the added information is good, this is a very complicated spec definition, so more information is better.
I just want to try and keep the doc generation as generalized as possible, it is not completely generalized already, but I want to prevent "degradation" if possible.

[CommanderStorm]

I just want to try and keep the doc generation as generalized as possible, it is not completely generalized already, but I want to prevent "degradation" if possible.

I don't fully follow what you are trying to communicate 😅

[CommanderStorm]

unrelated, but was a bad idea to include.