Non-formatting ICakeConsole.WriteLine overload

[jnm2]

Would you consider adding non-formatting Write and WriteLine overloads to ICakeConsole?

Let's say I want to write Information("[0] dll vendor 12 bytes {0} [built]") or something similar in my Cake script. This errors out because it's getting passed as ICakeConsole.WriteLine("[0] dll vendor 12 bytes {0} [built]", new object[0]).

The only workaround is for me to escape every { and }, but that's not the .NET way. I can write a format-escaping method but that's quite a lot of overhead to just blit a literal string with no format parsing.
The .NET way allows Console.WriteLine("{0}") but does not allow Console.WriteLine("{0}", new object[0]).
That's the root cause of the issue @pitermarx was having with my process output-buffering script: the NPM process outputs the literal string {0} and of course I'm forced to pass that to ICakeConsole.WriteLine.

My immediate problem is that I have an ICakeConsole instance and need to write a literal, unparsed string. So I want to be able to call ICakeConsole.WriteLine(literalString) and not have it be parsed as a format string.
I think the best solution to that problem is to introduce the overload ICakeConsole.WriteLine(string) alongside the existing ICakeConsole.WriteLine(string, params object[]).

The reason for a new overload is that if I call ICakeConsole.WriteLine("{0}", (object[])null) or ICakeConsole.WriteLine("{0}", new object[0]), that should be a bug and I should get an error, like the way the .NET BCL works.
Without the new overload, 1) you can't detect when null or empty is really a bug and 2) you have to rely on implementors to know about checking for null or empty to change the meaning of the string.
With the new overload, whoever implements ICakeConsole will immediately see what's going on.
Plus, XML documentation will guide both implementors and consumers of the API.

^{(Via https://gitter.im/cake-build/cake?at=587ce7bedec171b811f6b7aa)}

[devlead]

Adding a method to the interface would be an breaking change, adding 2 extension methods would not be, similar to what's done in #1456

[jnm2]

@devlead Oh, I see the PR. Interesting.

[jnm2]

Unless you want the ICakeConsole implementors to be able to separate and colorize the args, I'd prefer the breaking change to remove the args parameters and use extension methods to string.Format. That means implementors won't be responsible for the string.Format logic. But yeah, I guess breaking changes aren't awesome even in 0.x releases.