Bump dora to 0.3.7-rc1

Minor dependency fix

Fix typo

Runs a dataflow locally, without requiring any any daemon or coordinator
processes. Multi-machine dataflows are not supported. The default log
level is set to `INFO`, overwriting it is possible by setting the
`RUST_LOG` environment variable.

This exposes the internal `dora daemon --run-dataflow` command that we
use for testing.

This addition was proposed in
https://github.com/orgs/dora-rs/discussions/698#discussioncomment-11125465
.

The second commit adds a ctrl-c handler. On first ctrl-c, we send a stop
command to all nodes. On second ctrl-c, we exit immediately and kill all
spawned nodes. On third ctrl-c, we abort the process directly without
waiting (child processes keep running).

Make `dora-message` a dependency of `dora-core`, instead of the other way around. This way, we can continue to freely bump the version of `dora-core` with the other workspace crates, without introducing errors such as #708.

Runs a dataflow locally, without requiring any any daemon or coordinator processes.

This exposes the internal `dora daemon --run-dataflow` command that we use for testing.

This addition was proposed in https://github.com/orgs/dora-rs/discussions/698#discussioncomment-11125465 .

It is necessary to make build multiline in order to build certain node. 

This allow users to do the following:

```bash
nodes:
  - id: dora-microphone
    build: |
      pip install -e ../../node-hub/dora-microphones
      pip install -e ../../node-hub/dora-vad
    path: dora-microphone
```

or

```bash
nodes:
  - id: dora-microphone
    build: |
      sudo apt install abc
      pip install bar
    path: dora-microphone
```

This PR fixes one error that happen when the coordinator fail to connect
to the daemon and ultimately hangs indefinetely.

## To reproduce previous behaviour:

```bash
dora up
kill <DAEMON PID> && dora destroy
dora destroy # <- This hangs
```

Fix: https://github.com/dora-rs/dora/issues/253

## Before

dora daemon --coordinator-addr 127.0.0.1:53290

dora daemon -c 127.0.0.1:53290

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.

First step towards versioning the message definitions indepedently.