Gadu-Gadu protocol update and patch

[Tomasz Sałaciński]

Hi,
GKeyFile is an interesting choice, as you seem to use it only as a
> hash table, with only one category.  Is there a particular reason you
> did not use GHashTable?  The use of GKeyFile will be OK for Pidgin
> 2.7.0, as it requires only glib 2.6, but it cannot be merged before
> 2.7.0.
> 

I use GKeyFile because it's more extensible - I can use it in the future for other things and it's very easy 
and clean to understand when you're reading the code. GHashTable lookup requires a valid pointer,
which I can't pass to the ggp_send_image_handler function as this function is called by event triggered
by libgadu, not libpurple.

It works like this:

1. User sends message with images
2. Client A(Pidgin) sends the message and crc, name and size of the image to client B (original Gadu-Gadu client)
3. Client B sends gg_image_request event to client A - requests image with particular crc.
4. Libpurple handles this with ggp_send_image_handler, so associations between image id and crc32 need to be stored
globally. I can't pass any pointer to this function. It just finds the crc and corresponding image id and sends the
"data" section of image from the store.

I can work around this by using a pointer array - if you have no problem with more than 11 variables in GGPInfo struct.

As for the libgadu version - no, newer libgadu is not required for these patches to work
(or at least shouldn't, it just changes the way the old gg prpl behaves). I've included it because of security 
fixes (and few feature enhancements).

There's an updated version of the patch:

http://alarm-clock.pl/gg_images_gg.c-2.patch

The only change is sending image to Gadu-Gadu 8.0 client. This requires any character after the image,
so libpurple adds a space, so user that doesn't know this will be able to send images to Gadu-Gadu 8.0 client.

If someone wants to test the GG protocol, feel free to email me and I'll create an account for you.

Regards,
Tomasz Sałaciński