Add support for qwenvl2 :)

* fix issue and more

When checking the CI:
https://github.com/dora-rs/dora/actions/runs/10806599829/job/29975721567

It appears that trying to destroy a coordinator that is not connected
does not raise an error. This makes it hard to debug as we do not catch
early stopping of the coordinator in that case.

C Node Template used to read the ID string that was not null terminated
making it read non UTF8 strings,

This fixes this issue by using the `id_len` to define the string.

## Before

```
[c node] dora context initialized
I heard Hello World from speech-2 at 7413312390293631648
I heard Hello World from speech-1� at 7413312390293852048
I heard Hello World from speech-1rld at 7413312390724241040
I heard Hello World from speech-1 at 7413312391153242512
I heard Hello World from speech-1rld at 7413312391583614704
I heard Hello World from speech-1 at 7413312392013829936
I heard Hello World from speech-1 at 7413312392445357008
I heard Hello World from speech-1 at 7413312392869967824
I heard Hello World from speech-1 at 7413312393300188464
I heard Hello World from speech-1 at 7413312393728743248
I heard Hello World from speech-1 at 7413312394163419488
[c node] received input closed event
I heard Hello World from speech-2 at 7413312398882741200
[c node] received stop event
```

## After

```
[c node] dora context initialized
I heard Hello World from speech-2 at 7413314362653395744
I heard Hello World from speech-1 at 7413314362653612304
I heard Hello World from speech-1 at 7413314363085816864
I heard Hello World from speech-1 at 7413314363514843808
I heard Hello World from speech-1 at 7413314363944633504
I heard Hello World from speech-1 at 7413314364373638000
I heard Hello World from speech-1 at 7413314364802237744
I heard Hello World from speech-1 at 7413314365230875824
I heard Hello World from speech-1 at 7413314365659380208
I heard Hello World from speech-1 at 7413314366092720496
I heard Hello World from speech-1 at 7413314366519381008
[c node] received input closed event
[c node] received stop event

```

This PR:
- gives unique test file names
- add test for each node main function until dora-rs node initialization
error in order to catch all dependency issues.

# Objective

Hi! This PR proposes several changes to the installation process,
`README.md`, and examples to make it easier for beginners to get started
with Dora.

## Installation

- The `install.sh` script for Linux and macOS now automatically detects
the user's terminal and asks if they want to add `.dora/bin` to their
PATH automatically.

- A new `install.ps1` script does the same for Windows. The following
command (note: it doesn't work yet because this PR hasn't been merged
into the main branch, so the path needs to be adapted) works regardless
of whether the user is in CMD, bash, or PowerShell (this helps avoid
potential errors):
```bash
powershell -c "irm https://raw.githubusercontent.com/dora-rs/dora/main/install.ps1 | iex"
```

=> I believe having a standalone installation script will help convince
more beginners to use Dora (especially among students/teachers). Using
`crates.io` requires several steps, particularly on Windows:
**installing Rustup**, simultaneously **installing MSVC**, and then
installing `dora-cli`. For many who are not Rust developers, this can
involve too many steps (especially regarding MSVC, since the Visual
Installer interface is not very intuitive, and beginners might not know
what to install).

## README.md

I was inspired by existing GitHub projects to propose a clearer
`README.md` that quickly highlights the important steps of the project:
**Highlights**, **Installation**, and **Documentation/Getting Started**.

## Examples

I haven't worked on this part yet, but I think it's necessary to rework
our `examples` folder. I find it easy to get lost in it as it currently
feels more like a `tests` directory than examples meant to guide a user.

What would be helpful is:
- Creating more explicit examples like `rust-talker-listener`,
`python-video-capture`, `rust-speech-to-text`, `python-ros2-bridge`,
`multiple-machine-talker-listener`, etc., instead of just
`c++-dataflow`, `python-dataflow`, etc.

- Automatically integrating all our examples into the `CI`.

- For the `python` examples, to facilitate execution with `run.rs`
scripts, it might be worth considering using `uv`
(<https://github.com/astral-sh/uv>), as they offer a crate that allows
managing an entire `python` installation, `venv`, `dependencies` from
Rust. This might be simpler than having to find a Python binary, install
everything, etc.

Co-authored-by: Haixuan Xavier Tao <tao.xavier@outlook.com>

Hi! I took a look at our `examples` directory, and while reading through
some dataflows, I noticed that there are a lot of outdated node
syntaxes:

```YML
nodes:
  - id: rust-node
    custom:
      build: cargo build -p benchmark-example-node --release
      source: ../../target/release/benchmark-example-node
```

I think it would be better if we avoided using deprecated syntax in our
example folder, as it will be one of the first things people look at.

# Bad latency

Hi! I noticed some time ago that I was experiencing really bad latency
when running:

```bash
cargo run --example benchmark
```

Even with:

```bash
cargo run --example benchmark --release
```

The latency was still completely off (which is somewhat expected, as
Debug mode can cause strange behavior):

```
size 0x0     : 615.092µs
size 0x8     : 623.942µs
size 0x40    : 718.112µs
size 0x200   : 1.217172ms
size 0x800   : 2.244282ms
size 0x1000  : 612.062µs
size 0x4000  : 525.111µs
size 0xa000  : 436.742µs
size 0x64000 : 211.722µs
size 0x3e8000: 595.502371ms
```

The issue was in the `run.rs` file, which was building and running the
`dora-cli` package in Debug mode by default. I added the `--release`
flag, and now it works well with both:

```bash
cargo run --example benchmark
```

and

```bash
cargo run --example benchmark --release
```

```
size 0x0     : 294.362µs
size 0x8     : 254.392µs
size 0x40    : 216.332µs
size 0x200   : 260.562µs
size 0x800   : 276.582µs
size 0x1000  : 222.322µs
size 0x4000  : 322.171µs
size 0xa000  : 253.342µs
size 0x64000 : 264.991µs
size 0x3e8000: 133.882µs
```

# Bad bandwidth

I also noticed really poor bandwidth for data transfer:

```
size 0x0     : 12856 messages per second
size 0x8     : 22945 messages per second
size 0x40    : 26058 messages per second
size 0x200   : 43542 messages per second
size 0x800   : 36324 messages per second
size 0x1000  : 25768 messages per second
size 0x4000  : 6855 messages per second
size 0xa000  : 3476 messages per second
size 0x64000 : 395 messages per second
size 0x3e8000: 44 messages per second
```

This was caused by regenerating random numbers for each test. I don't
think we should do that because it doesn't align with our benchmarking
goals—we want to measure the latency of transmitting a known message and
the associated bandwidth.

Now that I generate the data **before** transferring it, I get much
better (and more representative) benchmark results:

```
size 0x0     : 8281 messages per second
size 0x8     : 24399 messages per second
size 0x40    : 19108 messages per second
size 0x200   : 19656 messages per second
size 0x800   : 34075 messages per second
size 0x1000  : 19251 messages per second
size 0x4000  : 21178 messages per second
size 0xa000  : 19627 messages per second
size 0x64000 : 8141 messages per second
size 0x3e8000: 1346 messages per second
```

Hi! The installation script introduced in #600 is excellent! I think
most beginners really need something easy to execute, especially
students.

I changed the final message to provide more useful instructions for
appending directly to `.bashrc` or `.zshrc`, so the Dora CLI is now
accessible everywhere, every time, without needing to source your path
again and again when you change your terminal.

Here’s how it looks for ZSH:

```bash
echo 'export PATH=\$PATH:$dest' >> ~/.zshrc
source ~/.zshrc
```

Of course the user can decide to not append his path.