raw / verbatim / literals
**Is your feature request related to a problem? Please describe.** 🤔

It's frustrating to always have strings piped through the various macro layers  such as strformat. On the frontend, it's still going to be better sometimes to pass or accept data from external JS scripts that communicate with literal strings. 

**Describe the solution you'd like** 💡
An equivalent idiom of Karax's verbatim, for direct injection of HTML->Dom would be nice.
In line with the idea of taking care of things under the hood, it would also be good to recognize the raw string literal types `nnkStrLit..nnkTripleStrLit` from nim and never apply strformat to them.

**Describe alternatives you've considered** 💁‍♀️
text tags from karax are acceptable for me since I use code snippets, but the more macro intensive approach here seems to want to be more aggressive about minimizing keystrokes along with boilerplate

**Additional context** ✌

I don't know how much you've tried to squeeze out of Karax in its current state, but here are the idioms for JS scripts that I'm familiar with in the buildHtml environment there:

```
script(): text """
  var params = {"appName": "graphing", "width": 800, "showTaskbar": true}
  var myApp = new App(params,true)
  myApp.inject("myID")
  """
```
Note that since JS is untyped, there can be some strange datatypes that are hard to exchange between nim and js. This means that some things from external libraries are better off implemented as pure JS commands, especially in an initial testing phase that needs to be quick. Another natural use case is talking about the literal syntax of code, which is one thing that one would naturally want to do on websites:

```
text """to properly template the string with the right user id and score, you type:"""
tdiv(class="code"):
  text """ Your score is {{ fmt{score,0.2d} }}"""
```

There are many uses for a verbatim as well. One that I am familiar with is inputting mathematics. MathML is excessively verbose, so inputting latex is better. But both MathJax and katex (in auto-render mode) fight with Karax' control of the DOM at present and shut down Karax' reactivity. So the next best bet is to bind katex ability to render string to mathML and then inject it into the DOM verbatim

```
proc renderToStringKatex(s:kstring): kstring {.importjs: "katex.renderToString(@)" .}
proc renderKatex(s:kstring): VNode = buildHtml:
  verbatim(renderToStringKatex(s))
```

Then build from there to interpolation of strings with inline latex.  Note that this is considerable effort compared with having Katex' auto-render work correctly out of the box. One thing that your approach with routing on the front end seems to help with is giving a little bit more leeway to other reactive scripts while still getting its own job done!

 Using routes on the front-end DSL should help a lot for writing code in a common source file while effectively managing user experience and computational resources.