redefining "put" and "OutputRange"

[monarch_dodra]

I'm starting this thread, first, as a shamless plug to a brand 
new pull I just did, which (amongst others) allows "put" to 
transcode on the fly any string/char of any length, to any 
string/char of any length.

This fixes issues mostly in std.format, and also allows things 
like formattedWrite to work with pure delegates (it didn't 
before), as well as output directly in wstring or dstring format 
(awesome for writing to a UTF-16 file, for example).

--------

The real reason I'm starting this thread is I believe the current 
way "put" leads to a *MASSIVE*, *HORRIFYING* issue. I dare not 
say it: Escaping references to local stack variables (!!!).

Basically, if R accepts an "E[]", than put will accept a single E 
element as input, and convert it to an "E[]" on the fly, using 
"put(r, (&e)[0 .. 1]);". I'm sure you can see the problem. It 
allows things such as:

//----
void main()
{
     Appender!(int[][]) app; //A type that accumulates slices
     put(app, 1);
     put(app, 2);
     put(app, 3);
     writeln(app.data); //prints: [[3], [3], [3]]
}
//----
Oops!

I'd like to make a proposition: "put" needs to be changed to 
*not* accept putting an E into something that accepts E[]. There 
is simply *no way* to do this safely, and without allocating 
(both of which, IMO, are non-negotiable).

For objects that define put/opCall, then it is not very 
complicated to have two different signatures for 
"put(E[])"/"opCall(E[])" *and* "put(E)"/"opCall(E)". This makes 
it explicit what is and isn't accepted.

Lucky enough, the problem never existed with input ranges: 
"int[][]" never accepted "int", so there is no problem there.

The last thing remaining are "sinks" (delegates and functions). 
As a convenience, and *only* for characters sinks, because we 
*trust* them to make local copies of elements, we can allow 
things like:
put((const(char)[]){}, 'a');// OK
put((const(char)[]){}, '本');// OK
put((const(char)[]){}, "hello"d);// OK
put((const(wchar)[]){}, "hello"c);// OK

This, I think, is what is safest, but still leaves a little open 
door, exceptionally, for easy formatting.

--------

So, the idea is now to yay or nay my change proposal, and/or 
discuss my pull:
https://github.com/D-Programming-Language/phobos/pull/1534