feat(errors): add suggestions and options to errors

[thde]

Depends on: #348

This MR introduces a custom error that can be used to add context and suggestions. It also uses standardized exit codes:

❯ nctl get postgresdatabase
 ✗ No "PostgresDatabases" found 💥

Project: ninetest

Suggested actions:
  - List all PostgresDatabases in your organization: nctl get postgresdatabases --all-projects

❯ nctl auth set-project fsdddld
Warning: Project "fsdddld" does not exist in organization "ninedasdad", checking other organizations...

 ✗ Project "fsdddld" not found 💥

Available:
  - demian
  - nine-staging
  - ninetest

Suggested actions:
  - Project names always contain the organization name:
    nctl auth set-project <org>-<project>

[thirdeyenick]

Overall I really like the custom error and think it might be usable in one or the other place 👍

[thirdeyenick]

👍

[pawelkuc]

I think that the biggest long-term risk is misclassification of errors.
People will start wrapping everything as a usage error because it looks nice.
Maybe we can provide here some rule of thumb, like:
usage error: user typo, missing flag, invalid value ...
forbidden: permission/auth ...
etc...

[pawelkuc]

some helpers here (under api/...) start returning internal/cli.Error directly. That's totally fine as our api is internal (for now). But it would be good to clarify this intention somewhere (and be consistent).
Or maybe we can have api return more semantic errors that get wrapped later?

[pawelkuc]

With this MR, nctl error output becomes structured.
People will probably start depend on it at some point, e.g. shell scripts grepping output or tests asserting error messages. I don't mean we should lock it totally, but maybe we can check more stuff here, like: iteration order, emoji placement, spacing before/after, indentation of multi-line messages, etc...