Feature request: `WARNING: this project is being migrated` message should not be printed to the same stream as actual errors

[jasonkarns]

Given a project with some known violations ignored via .standard_todo.yml.
And the project has additional violations.
When standardrb is run.
Then both the violations and the "migrated" warning should not be printed to the same output stream.

Rationale:

STDOUT is meant to contain the desired output of a command. (That is, the output represents the intent of the command; aka the output for which the command was run.)

STDERR is meant to contain diagnostic output that is not the primary purpose of the command. Typically this means it contains error messages and debugging information that is secondary to the intent of the command.

This split allows, for example, structured output to go to stdout without having debugging/informational/diagnostic messages breaking the syntax of that output stream.

The distinction gets murkier when the intent of a command is to find and catch errors. standardrb is silent when all is well. But its purpose is to identify violations. Presently, any such violations are printed to STDOUT. This is fine. The whole reason one runs the standardrb command in the first place is to find violations. (One could argue this output should go to STDERR because they are errors; but I think STDOUT is correct because that output is the express purpose of the command.)

However, if a project has known and ignored violations specified in the todo.yml, then that warning message is also printed to STDOUT. Since these two distinct bits of information are on the same stream, there is no way to selectively ignore one bit without the other.

I propose that the migration/warning message be directed to STDERR. This would enable:
standardrb 2>/dev/null to print any unexpected violations to STDOUT (as it does today), while hiding the secondary diagnostic warning message by sending it to /dev/null.