rustup check: add exit status and no-self-update logic

[tjkirch]

First:

rustup check: adopt no-self-update logic

The 'self update' subcommand checks whether self updates have been
disabled, but 'check' did not, meaning the check output could include
updates you're powerless to accept.

This adds the logic from self update to check, no longer showing updates
that can't be applied by rustup, along with its --no-self-update flag,
in case you *are* able to update rustup but don't want to check it for
updates at the moment.

Then:

rustup check: set exit status based on available updates

This helps with interfaces above rustup, for example prompting a user to
update, but only if updates are actually available.

If any updates are available, exits 0, otherwise exits 1.  This allows
"natural" shell commands like 'if rustup check; then <update>'.  It also
mirrors existing exit codes for update, where rustup exits 1 if updates
are not permitted by the distribution or because of errors.

My use case is as described in the second commit: building a little interface on top of rustup to help a user stay updated, but not prompting them if there's not actually an update available. It was fairly easy to add an exit code to rustup check to represent what it found about available updates.

I'm using a distribution-managed rustup, so seeing rustup updates in this process isn't actually useful; I see they're available but can't rustup self update to take care of them. I thought it made sense to use the same logic as in rustup self update to determine whether to show self updates in check. And since self update has an argument to force hiding that output (even if you can update) I did the same in check.

---

One potential downside here is the change in behavior of the exit status of check, which is currently 0 regardless of available updates, unless rustup had an error. I believe this to be minor, given that an exit of 1 in existing code didn't really give an option for automated recovery, which matches the "nothing to do" result of 1 for not having available updates with this change. But I'd understand feedback about wanting a different exit code, or requiring a new flag to activate use of these exit codes.

Another potential downside is the removal of some output of check in the no-self-update case. I see this as minor for a similar reason; there was nothing you could ask rustup to do with that output. If someone is using it to automate checks for rustup updates without actually using rustup for updating itself (?) it seems there are better ways.

---

To test, I found that I could force an available toolchain update by removing its manifest file, and force a rustup update by lowering its version in Cargo.toml and reinstalling it to the test prefix. So, I tested each combination - no updates, toolchain update, rustup update, and toolchain + rustup update. I also tested with the no-self-update feature to confirm rustup updates are no longer shown, if desired.

[tjkirch]

^ This push fixes the relevant tests to expect the new behavior/output. (I wasn't able to run tests earlier, but found that it was just flaky network tests and I could rerun them a few times.)

[rami3l]

Nice catch about the inconsistencies, and many thanks for the PR :)

[tjkirch]

^ This push attempts to address the requests above by flattening CheckOpts and rebasing onto master to use the new testing APIs.

[tjkirch]

^ This push updates to use extend_redactions in check_updates_self_no_change as requested.

[rami3l]

LGTM :)