Support exporting with alternative line endings (e.g.: CRLF)

Hi DanChadwick, thanks for your review!

The need for CRLF: (sadly) a lot of companies and organizations rely on software and protocols that aren't that flexible when it comes to how data is handled. In my specific usecase, the whole backend administration of a town (±60000 inhabitants) runs on these CSV files with CRLF. They can't just change the software to use LF because that would break all other programs that feed csv to it. In general, most applications that do csv exports have 2 options: delimiter and line endings, so it does make sense to me (hence me writing this as a patch instead of just another contrib add-on module.)

The global default: I guess I can remove that if you want.. It just made sense as the delimiter setting is also global and both are kinda related. Perhaps I just hardcode it?

The need for CR: none really.. I removed it.

Not sure what the issue is with the drush command?

In any case, here's a new patch

I'm ok with a blind config variable!
As for changing the default to CRLF: NOOoooo!! I bet that would break 1000s of workflows, as you say yourself: 400,000+ installations!

Shall re-roll a patch soon, got some other stuff to do first!
How/where should I document it?

Sadly, this change doesn't work the way it should.
if you variable_get the line_ending, you get a literial string (ie.: you get the equivalent of '\n' instead of "\n")
The resulting CSV file wil just contain the string \n at the end of every line, except when using the default setting.
This is why in my original patch I hardcoded the line endings.
This is also why the webform_exporter_delimited class contains code like this:

    // Convert tabs.
    if ($this->delimiter == '\t') {
      $this->delimiter = "\t";
    }

I did a little research and it seems like there isn't a good fix for this, it cannot just be converted: https://bugs.php.net/bug.php?id=43901
I also read:

you can call functions within string escapes, so this is just as dangerous as eval() anyway.

So basically, I think the variable method of storage should be changed back to CR/LF/CRLF/.. strings like I did in my original patch, and do the conversion in a switch case.

I'm willing to provide a new patch for this, what do you think @DanChadwick?

@DanChadwick
Sorry about that, you are right. I had set the variable using drush vset, it appears there's no way to do it like that (or at least, not a way I know of).
See:

variable_set("test", "test\n");

rv0$ drush vget test
test: "test\n"

rv0$ drush vset test "test\n"
test was set to "test\n".                                                                                                                   [success]
rv0$ drush vget test
test: test\n

Funny! See how the output is different the 2nd time I run vget.. I'll see what I can find about this, at least it is documented here already ;)