Unify binaries usage instructions

[0x009922]

Description

The documentation mentions usage of binaries from Iroha repo in many places all across itself. Mostly those are iroha, iroha_client_cli and kagami. In some of these places such mentions are accompanied by instructions of how to build a particular binary, or even install it system-wide. These instructions are repetitive and inconsistent between each other:

• Some of them execute binaries directly, e.g. kagami ..., but others do it via Cargo, e.g. cargo run --bin kagami -- .... Sometimes it is cargo build with using the built binary file located at target/<target>/<binary> .
• When using via Cargo, sometimes it is in debug (default) mode, but in other times it is with --release flag.
• Some of them mention installation of binaries into PATH var, others do not

In order to reduce repetition, I suggest introducing a single unified section which explains how to build/install/run Iroha binaries.

There are two ways:

• Using pre-built images from Dockerhub. iroha, iroha_client_cli and kagami might be used through Docker without installation of Rust toolchain, but requires Docker to be installed
• Building from sources on GitHub. This, first of all, requires installation of Rust toolchain, which gives us cargo binary in the system. Then there are the following options:
  • Use cargo install --git <iroha git repo> <binary>: the simplest way to get the <binary> installed system-wide, without manual clone of the repo
  • ...or clone the repo manually, and then cargo install --path /path/to/crate/in/repo. This is a little more complicated, because we cannot specify just name of the <binary>, but should replace it with particular paths:
    • iroha → <repo>/cli
    • iroha_client_cli → <repo>/client_cli
    • kagami → <repo>/tools/kagami
      (actually, it is a good place to think about renaming of the directories, so that the mapping will be direct. See also: [suggestion] Restructure the Iroha repository iroha#3773)
  • ...or (with cloned repo), build the binaries manually (without system-wide installation) with cargo build --bin <binary> --release. The binaries will be located at target/release/<binary>, and user might manually add them to PATH if they want, or simply use as-is.
  • ...or (with cloned repo), run the binary directly via Cargo with cargo run --bin <binary> --release -- .... This is a shorthand version of the cargo build & manual binary usage.

Those parts of the docs that mention binaries usage should refer to this unified section, saying that the reader might find installation instructions there. Then, without complications, all code snippets will presume that the binary is installed system-wide and invoke they simply by name. For example:

# Old
cargo run --bin kagami -- ...
cargo build --bin kagami
./target/release/kagami ...
docker run ... # i forgot the arguments

# New
kagami ...

Benefits

Less repetition, more consistency, instructions are collected into a single solid guide.

Downsides

Requires extra effort to integrate this section into the documentation so that it is both comprehensible and referable.

[6r1d]

This idea sounds good. Even if there is some context of builds we may miss right now, it will be uncovered in the process.