vdoc: refactor html_highlight and handle strings with string interpolations (eg. ${a}.${b}.${c})

[nedpals]

The goal for this PR was to fix the issues with highlighting strings with string interpolations (of which I call them as "complex strings"):

• html_highlight misses most of the code that should be highlighted due to the index greater than the string token's byte index. This is triggered for call expression that have complex string as an argument.
• String dollar / string interpolation sign not recognized properly.
• String quotes are added to the string content automatically regardless of the position. (eg. "${a} world" -> "${a}"world")
• Closing curly string interpolation brace is only rendered when the content of the string on their right is side is empty. (eg. "${a}.${b}.${c}" -> "${a.${b.${c" )

A refactor inside html_highlight was also done in order to make the fix possible and to make the code more manageable (and more performant, I suppose) as more rules are added.

Photo: left: w/ fix, right: w/o fix (sorry if it's reversed)

🤖 Generated by Copilot at 8a3970e

This pull request enhances the vdoc tool by improving the syntax highlighting of string interpolation and builtin types in both HTML and terminal output. It also refactors some common code to use a strings.Builder and a shared array of highlight_builtin_types.

🤖 Generated by Copilot at 8a3970e

• Add support for string interpolation syntax highlighting in HTML output (link, link, link)

• Define new enum values for interpolation tokens in HighlightTokenTyp (link)
• Replace highlight_code function with write_token function that writes to a strings.Builder (link)
• Handle interpolation tokens in html_highlight function main loop (link)

• Refactor builtin array to module level and rename to highlight_builtin_types (link, link)
  • Avoid duplication and improve maintainability of builtin type names in utils.v (link)
  • Use highlight_builtin_types array in both html_highlight and color_highlight functions (link)

[spytheman]

Please add a test, that can be run to check that the new functionality will not regress.
Screenshots are nice for people, but imho generating a bunch of html, from a known source, then checking that the generated html has specific things in it, will be easier to test automatically.

[nedpals]

Still in the middle of adding tests and further documentation but had no time at the moment. Will reopen this at a later time.

[ttytm]

Good work guys!