bug#40407: [PATCH] slow ENCODE_FILE and DECODE_FILE

[Mattias Engdegård]

Eli, thank you very much for thinking about EOL conversion; obviously I didn't. 
I fixed a couple of glitches: a variable was used uninitialised, the logic 
didn't quite work for both unibyte and multibyte, and unless I'm mistaken it's 
LF that we should look for when encoding, not CR? Anyway, hope you don't mind.

The alternative would be to skip the no-conversion shortcut whenever EOL 
conversion applies, but memchr is quite fast and it's all likely to be in D1$ 
by that time.

I also need to thank Ogawa-san again for drawing my attention to 
check-coding-systems-region which crashes Emacs (SIGABRT) if given an invalid 
encoding; fixed.

An exhaustive search for other encodings that erroneously were marked as ASCII 
compatible found only one (chinese-hz); now fixed.

The calls to {ENCODE,DECODE}_FILE messily mutating the returned string have now 
also been fixed, along with a potential GC bug.