TextEncoding iconv instances are shared between threads

[batterseapower]

The icon_t pointers returned from iconv_open should only be while processing a single text stream, because in general they may contain some state about the text being processed.

However, we currently don't take any measures to prevent this from happening, as GHC.IO.Encoding.Iconv.mkTextEncoding shares one pointer amongst all use sites of that TextEncoding? in future -- even if those uses occur on different threads!

This could lead to arbitrarily strange heisenbugs depending on the iconv implementation.

Either we should:

1. Make it clear that the user should recreate a TextEncoding? anew for every use site

2. (Better), elaborate the TextEncoding? interface so that we can call iconv_open/iconv_close at the start and end of processing a particular text block, and ensure that the token doesn't escape so it can be accessed from multiple threads simultaneously

[batterseapower]

Sorry, this is wrong: this issue only effects the output of running mkText{Decoder,Encoder} so I'm not sure its as important as I thought. Probably still worth documenting though.

[batterseapower]

I documented the invariants on these things in 54a0b49. Current usage is safe because Handle is protected by a MVar, and in my (uncommitted) CString code the decoder/encoder only exist for the lifetime of a stack frame.