allow user control of expansion before/after  🔥
**Is your feature request related to a problem? Please describe.** 🤔
A point of frustration that has come up in other issues (#171 and #141) is that the order of evaluation in loops and other constructs is not always what one wants, and in particular, that a component + slot does not in general act like inlining the component code. One thing to think about is that sometimes the difference in behavior is a stumbling point and leads to bugs or slower coding, but other times the distinction between component and TagRef is useful and allows for finer control.

For example:
```
component Dup:
  n: int
  `template`:
    for i in 1..self.n.val:
      tDiv(style="color:red"): slot

appRoutes("ROOT"):
  "/":
    Dup(4):
      "slot is {rand(99)} "
    for i in 1..4:
      tDiv(style="color:blue"): "slot is {rand(99)}"
```

![image](https://github.com/HapticX/happyx/assets/126020181/4a527fa4-4bc3-442a-8fca-e17c8df6fbd3)

We could say that `Dup` works as intended, but there is currently _no way_  to code something equivalent to the raw `for` loop, at least not with components. Macros can delay execution, but currently the syntax is a little bit awkward if you want to have a code block as the last argument (they must be assigned to a variable then placed with {})

**Describe the solution you'd like** 💡
The distinction that we are talking about is basically quoted vs unquoted code in Lisp, or compiletime and runtime in nim. There's a slight difference here though in that we are talking about delayed excuation with regard to the 'compilation' process that applies the DSL to the DOM

Maybe it would be good to include keywords for indicating whether the code should expand before passing into a component/loop or after. Then

```
for i in 1..4:
  buildLater:
    {rand(99)}
```
would work the same as
```
for i in 1..4:
  {rand(99)}
```
But
```
for i in 1..4:
  buildNow: {rand(99)}
```
would work the same as
```
for i in 1..4:
  Dup: {rand(99)}
```
as given above.
If the syntax extended to handling slots within components, then `later(slot)` might be used to get the `Dup` component to behave as a for loop.

**Describe alternatives you've considered** 💁‍♀️
Templates provide the usual mechanism for delaying code execution in nim. They would work well if the DSL allowed direct calls to templates and macros as allowed Statements. But even if this were implemented, it seems like there should be a conventional set of commands (perhaps implemented as macros) that would define the type of delayed execution _within_ the framework that makes sense.

As the framework continues to develop, the way in which the intended delay or immediate execution is implemented might change, largely for lower level reasons.

Regarding syntax, attaching a parameter to buildHtml might also look good. So then `buildHtml(later)` could be used as `buildLater` above. But then `buildHtml` might also want to be placed as a block statement within the DSL, which may be a good or bad thing, depending on how macro support develops in the DSL.
