Windows fixes

[vguna]

What does it do ?

Exporting german filenames (UTF8) that contain umlauts (öäüß) gets messed up when writing
the files under windows. PHP5 under Windows does not support UTF8.

Also I encountered during my build/extract cycles, that there's a conversion of CR/LF in the gitify
code, that results in changed files after a build/extract - although nothing has changed. This is
inconvenient when comparing against SCM (shows the files modified),

Why is it needed ?

When exporting filenames, these are not correctly named under windows and are recognized as "new" when diffing against e.g. the SCM.

Related issue(s)/PR(s)

No PR yet. WDYT?

[Mark-H]

There are some related issues, like #167 and #50, so I think it makes sense to take a closer look at filename generation and line endings across all environments, not just windows.

[vguna]

Yes. Maybe having some kind of char whitelist for exporting/importing files would make sense. As long as the "real" filenames within modx aren't affected by that. As I read today, linux has no problem with utf8 filenames, but windows has. AFAIK PHP7 comes with UTF8 windows support. But I think not everyone is able to switch to 7 in the near future. So I agree this PR is more a temporary solution so I can get it to run under windows - now :).

Regarding CR/LF it isn't actually related to windows. I think gitify itself shouldn't change lineendings of content files at all. IMHO it should treat them as "binary" files.

[alroniks]

I agree about encoding filenames but disagree about file endings. By PSR all files should have \n symbol and almost all IDE adds this chars at the end of lines. I not sure but maybe as a solution, we can replace line ends by PHP_EOF constant (should get correct line end character from the system)