Remove dumb_println

[reem]

After #10965, which introduces no-context printing, this is no longer needed.

This PR changes the usage sites of dumb_println to just use println_args, which
passes all tests. However, I don't know enough about the intricacies of this
issue to know if this is a satisfactory replacement, even with #10965.

Fixes #11043

[brson]

I'm a little worried about this. rterrln! is called in some hairy situations, including right before aborting on out-of-stack, and by routing it through all the normal I/O stuff, it can end up doing a lot, including context switches. User-space descheduling right before a panic seems like a recipe for badness.

[reem]

@brson Do you think we still need dumb_println or is there a better function which might work here, other than println_args?

Travis failed but I'm unsure why.

[brson]

I don't have any good ideas offhand, no. One might identify the places where we absolutely don't want to go through the Rust I/O stack and separate out those cases (it may be just in util::abort). It does seem like we want to print something on abort if at all possible though, and that should ideally do little more work than go directly to the write syscall to avoid scribbling on random memory and causing more badness.

Perhaps @alexcrichton will chime in.

Travis has been failing a lot for unrelated reasons.

[alexcrichton]

The printing stack has a special case for when a local task is not available which is appropriate to use in the contexts that @brson mentioned. So long as you can guarantee that there is no local task available when invoking rterrln! I think you'll be ok. If you ever, however, call rterrln! when there is a local task available, lots of badness will likely ensue.

I feel like providing that guarantee (likely via Local::try_take) may not be worth it as this is such a small and simple function, so the issue may just want to be closed at this point (it has grown less relevant over time).

[alexcrichton]

Closing due to inactivity, but feel free to reopen with mine/@brson's comments addressed!