kci-dev possible roadmap

Trying to match what the dashboard offers I believe we can follow these steps (I listed the features in a decreasing priority order):

1. Add `kci-dev issues` command, with the following subcommands:
1.1 `kci-dev issues --origin ` that lists all issues from `origin`.
1.2 `kci-dev issues details --id ` gives detailed information of the issue with `id`. It supports multiple `--id` options.
1.3 `kci-dev issues tests --id ` lists all the tests related to the issue with `id`. It supports multiple `--id`.
1.4 `kci-dev issues build --id ` lists all builds related to the issue with `id`. You can query multiple issues using multiple `--id` options.
2. Add `kci-dev hardware` command:
2.1 `kci-dev hardware list --origin ` that lists all available hardware for `origin`.
2.2 `kci-dev hardware summary --id ` gives a summary on the builds, boots and tests run of the hardware with `id`.
2.3 `kci-dev hardware boots --id ` lists the boots for the hardware with `id`. The response is similar to `kci-dev results boots`.
2.4 `kci-dev hardware builds --id ` lists the builds for the hardware with `id`. The response is similar to `kci-dev results builds`.
2.5 `kci-dev hardware tests --id ` lists the tests for the hardware with `id`. The response is similar to `kci-dev results tests`.
3. Add `kci-dev results issues` subcommand. We can obtain this information via `api/tree/{commit}/full`, however, it would be best if there was a `api/tree/{commit]/issues` available, since `full` retrieves information we would just discard.
4. Add more options to `kci-dev results boots --filter` YAML filter. The new options could be: config, compiler, architecture.
5. Modify `kci-dev results` `--arch` option. It could allow filtering by various architectures by supporting multiple `--arch`.

Please let me know how this looks to you.

Review the existing `kci-dev results` commands and the proposed `issues` and `hardware` entry points in the issue. Compare the listed commands with the `api/tree/{commit}/full` endpoint and existing boots, builds, and tests responses. Done means agreeing on scope and implementing the roadmap items with corresponding command behavior and filtering.

Written by the indexing model from the issue text.