Use the new request/reply communcation layer and its TCP-based implementation for sending control messages from the CLI to the dora coordinator.

Queries the list of running dataflows from the coordinator and prompts the user to choose one.

Allow configuring the `dora up` behavior through a `dora-config.yml` file

Fix clippy warnings

* Add getting started  section in `README`

* Update README.md

Co-authored-by: Philipp Oppermann <dev@phil-opp.com>

* Update README.md

Co-authored-by: Philipp Oppermann <dev@phil-opp.com>

* Update README.md

Co-authored-by: Philipp Oppermann <dev@phil-opp.com>

Co-authored-by: Philipp Oppermann <dev@phil-opp.com>

The problem is that `op-1` get compiled into `libop_1.so` instead of `libop-1.so`.

The dataflow shared-library name would needs to be adapted afterward.

- dora node does not import the right config.
- The template print makes it look like there is an error without modification.

Implement dataflow templates in `dora new`

Implement `dora up` command to start coordinator and iceoryx RouDi

* Refactoring `dora-cli` start and stop to uuid only

To make selection of the `uuid` simpler, I removed the text of the start and stop command.

This makes `dora-cli` closer to the `docker-cli`.

This change make me able to do the following:
```bash
UUID=$(dora-cli start dataflow.yml)
dora-cli stop $UUID
```

* remove remove print UUID from dora-cli stop

CLI check wether dora-runtime and iceoryx daemons are running

Chrome does not permit opening HTML files from the tmp directory.

Parsing as URI does not work for relative paths, e.g. `../../foo`.

Makes it possible to set an URL as operator source. The `dora-runtime` will then try to download the operator from the given URL when the dataflow is started.

The message is not recognized by the nodes/operators yet. This will be done in a follow-up commit.

Allows replying to requests. We use this to send the dataflow UUID back to the CLI after starting it.