Add a way to suppress interactive prompts from the CLI

[Abstrct]

There are a number of cases in which an interactive response is now required by the CLI. Some examples of this include:

• The acknowledgement/choice about data collection for Ignite prompts the first time the CLI is used
• If the CLI detects a project is not using the newer buf build system, it prompts to ask the user if an upgrade should happen

These interactive commands provide a complexity when using ignite within automated processes, especially containers.

Solutions
I believe this could be resolved with 3 possible solutions, although I'm sure other perfectly acceptable solutions exist too.

• A --non-interactive mode flag
• A setting within ~/.ignite
• An IGNITE-NON-INTERACTIVE environment variable

Any of these methods that would suppress these prompts would ensure commands are not stalled by unexpected prompts.

Difference to --yes
There is a flag already in Ignite, somewhat similar in spirit, used purely to bypass the transaction signing confirmation. The --yes flag. This is similar in that is does bypass an otherwise interactive moment in the CLI, but I believe it differs due to its lack of negative choice.

The key issue in this particular feature request is that the automated system does not know what interactive question is being asked. I believe this makes the --yes flag inappropriate, as I may not want to blindly choose yes on a prompt that could related to data collection, migration of one build system to another, or other questions that I'm not present to read and understand.

For that reason, the --yes command is perfect for the tx sub commands of the CLI, but I don't feel like it is the best solution for these other instances of interactivity in the CLI.

[Pantani]

@Abstrct, thanks for the suggestions. We already have the --yes flag. I agree the name could be more intuitive. IMHO, we should only rename and fix the places that are not passing the interactive from the CLI

[Pantani]

@Abstrct, the -y is working again for all cases. It is the same idea as the --non-interactive flag. I will close this issue because we don't have plans to support both flag since is redundant

[Pantani]

thanks for the suggestion @Abstrct