Use tabset groups or use page switches for R/Python features

[coatless]

Consider auto-switching tabsets from R to Python by specifying a tabset group, e.g. for demo setup

Goes to:

::: {.panel-tabset group="demo-setup"}

# R

````markdown
```{{webr}}
for (x in 1:5) {
  print(10 + x)
}

# Python

````markdown
```{{pyodide}}
for x in range(5):
  print(10 + x)

:::

This allows the output to swap, e.g.

#### Output

::: {.panel-tabset group="demo-setup"}

# R

```{webr}
for (x in 1:5) {
  print(10 + x)
}

Python

for x in range(5):
  print(10 + x)

:::

Alternatively, you can go the route of having separate documentation pages showing the workflow for webR and Pyodide separately (gently saves bandwidth):

<img width="672" alt="Screenshot of the Quarto documentation's tool selector approach to the getting started guides" src="https://github.com/user-attachments/assets/7dcd5401-4dcf-4762-94b4-c88c2bf2227a">

Example:

Standalone by editor: 

https://github.com/quarto-dev/quarto-web/blob/9dd130e8f4184422051d8f2b94999b101c0e1b55/docs/get-started/hello/vscode.qmd#L9

Tool selector shared snippet: 

https://github.com/quarto-dev/quarto-web/blob/9dd130e8f4184422051d8f2b94999b101c0e1b55/docs/get-started/_tool-chooser.md

[georgestagg]

In the short term, I'm happy for all R and Python tabsets throughout the documentation to be grouped.

I'm a little less convinced about separating into multiple pages, at least for the moment. I'd be worried about prose duplication and the extra noise. Not saying "never", though.

---

It is true that we'd save some bandwidth separating out, but I think that both WebAssembly engines are heavy enough that loading either into a page is going to be practially the same damage as both.

If it becomes a serious issue, we might be able to tweak the setup on pages containing tabset groups so that it defaults to R and Pyodide is only actually loaded when a Python block is first made visible (Thinking about it, this might actually be a nice future feature to have for either engine).