Deprecate print_with_color

[ararslan]

print_with_color is an odd function; its name is rife with underscores and it violates our argument order conventions by putting the color before the I/O argument.

This PR replaces print_with_color with a more general function called printstyled, which accepts the color as a keyword argument to mimic the bold keyword. That is, print_with_color(:red, "hi", bold=true) is now printstyled("hi", color=:red, bold=true).

There was also an unexported Base.println_with_color, which has been removed entirely without deprecation.

[StefanKarpinski]

This is certainly an improvement. I wonder if it wouldn't make more sense to just have a generic Style(content, color=:cyan, bold=true) wrapper for content – where the content could be a bare string or another Style object or whatever and then you just call print on that. @KristofferC may have some thoughts as the author of Crayons...

[KristofferC]

The Style method is similar to how Crayon does it.

If we change print_with_color we should probably change with_output_style in the same way. Even though it is unexported it is frequently used outside Base (because it is quite useful).

[StefanKarpinski]

Should we just import (steal) parts of Crayons to replace this? print_with_color is exported (I had to check).

[KristofferC]

I can make a PR with a suggestion (after I have moved out REPL to stdlib). The name "Crayons" is perhaps a bit too cute for an stdlib but it could easily be renamed to something more descriptive.

[ararslan]

Something that's been suggested was to wrap the I/O argument in IOContext and supply color and bold information to the constructor. One issue with that is that IOContext already has color property that means something else: it's a Bool denoting whether the wrapped IO supports color (IIRC). It would be possible to deprecate that name to something like hascolor in 0.7, then introduce color to specify a color in 1.0, but I'm not sure that print(IOContext(STDOUT, color=:blue, bold=true), "hi") is actually a friendlier API.

[JeffBezanson]

It doesn't fully make sense to me that formatting style would be part of the IO context.

[JeffBezanson]

Let's just rename this to printstyled.

[StefanKarpinski]

Triage dixit: go with this PR (rename to printstyled) and merge. Something fancier could be added in the future but this can exist as a legacy interface.

[ararslan]

CI summary:

System	Status
Travis Linux x86	✅
Travis Linux x64	✅
Travis macOS	Timeout
AppVeyor x86	Timeout
AppVeyor x64	✅
Circle x86	✅
Circle x64	Unrelated
FreeBSD	✅

[ssfrr]

Triage dixit: go with this PR (rename to printstyled) and merge. Something fancier could be added in the future but this can exist as a legacy interface.

In the future could bold and color be added as keyword args to print rather than having a separate function, or does that cause some problems I'm not thinking about?