RemoteUser-supplied local file paths

[Mark Doliner]

This is email 2 of 2 concerning a probable CVE-worthy issue bought up
by Chris Wysopal and Veracode.  (As a reminder, email 1 of 2 concerned
MXit code and we've agreed that we'll obtain a CVE for those issues.)

In 2.x.y these files call purple_imgstore_add_with_id() and set the
filename to an unescaped value read from the network:
- libpurple/protocols/gg/gg.c:1402
- libpurple/protocols/oscar/odc.c:359
- libpurple/protocols/sametime/sametime.c:2785
The file is then written to disk in purple_buddy_icon_data_cache()
using the unescaped filename.  I'd love if someone could look at these
few bits of code and confirm that this problem is real and I'm not
wrong.

Possible fixes:
1. Update those three prpls to escape the filename using
purple_escape_filename() before calling purple_imgstore_add_with_id().
2. Update purple_imgstore_add_with_id() to escape the filename in the img.
3. Update purple_buddy_icon_data_cache() to escape the filename before
writing to disk.

Option #1 is the easiest and least intrusive, but leaves open the
possibility that I've missed a few places, and leaves open the
possibility of this problem recurring in the future.  Option #2 is a
little scary because I think we might use the "filename" field for
more than just the filename.  Maybe we use it as a hash table key?  Or
show it to the user as a friendly name for an image?  I don't know.

Anyone have an opinion?