Instead of sending `CoordinatorStopped`.

This should make it easier to debug when a reply is not sent as expected.

The coordinator now sends an immediate `DataflowStartTriggered` reply when receiving a `DataflowStart` command. This enables the CLI to directly attach to the dataflow and observe the build output.

To wait until the build/spawning is done, this commit introduces a new `WaitForSpawn` command, to which the coordinator replies with a `DataflowSpawned` message once the node has been started. We use this command for the `dora build` command.

Instead of running all the build commands directly, run them on their intended target machines through the coordinator.

This commit is a breaking change because a coordinator connection is now required for `dora build`.

Avoid performance overhead.

Add comments on why we check the handling time.

Still log unexpected errors

Send an exit message from the daemon to the coordinator on exit. This enables the coordinator to disconnect the daemon properly instead of waiting for a missed heartbeat signal.

The previous machine ID is still used, but optional. Users don't need to ensure that the chosen machine IDs are unique anymore because they are augmented with a UUID.

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.

Previously, When a daemon stop it sends a message to the coordinator
which will log it as an archived dataflow even though not every daemon
has stopped within the dataflow.

This PR should fix this issue.

* fix issue and more

First step towards versioning the message definitions indepedently.

We need to avoid blocking the coordinator for too long.

Allows to override the log level through the `RUST_LOG` env variable.