Try to fix broken Unicode in some messages

I've honestly no idea why this is needed. As far as I can see, $text has
the same contents, utf8::is_utf8($text) returns 0, and utf8::valid()
returns 1, in both 'working' and 'broken' cases.

    (For historical record: 'broken' means that factoid contents get
    double-encoded when they were triggered by the 'idle' mode, even
    though it's exactly the *same* code that also generates 'working'
    factoids upon request. The output of &Report (e.g. "X taught ...")
    is also broken.)

Oh well. I'm not the first one, nor probably the last one, to be
confused by this. But at least I can hack around it.
Fix broken Unicode properly this time

If the strings are identical, there must be something else that differs.

Turns out, it's the channel name ($chl) – in some invocations, it has
the is_utf8 flag set (e.g. when idle-chatting).

When POE::Component::IRC creates the final line with "$state $to :$msg",
Perl sets is_utf8 on it if /any/ of the input strings had it, but won't
utf8-encode strings that didn't. (Instead, they get included as if each
byte was an individual codepoint.)

To fix this, always make sure POE receives only raw byte strings, by
encoding them when necessary.
Copy the fix to action()

On a related note, `my $text = "@_"` could cause the same bug in a
slightly different place. This is currently not a problem, since say()
is never called with more than 2 args. But if it ever becomes a problem,
this could be replaced by adding:

    for ( @_ ) { utf8::encode( $_ ) if utf8::is_utf8( $_ ); }

as the *very first* line inside say() and action(). Rather ugly though.
Merge pull request #44 from grawity/unicode-♥

Fix semi-random Unicode errors!