Fix tiny memleak when custom browser command doesn't work.
This is new code since 2.10.7, so this leak doesn't exist in
the wild.
Upgrade NSS to 3.15.4
Add ChangeLog entry for datallah's 932b985540e9.
I guess we should get a CVE for this?
Prevent spoofing of iq replies by verifying that the 'from' address
matches the 'to' address of the iq request.

This full extent of this problem was realized by Thijs Alkemade, while
investigating a problem reported to us by Fabian Yamaguchi and Christian
Wressnegger of the University of Goettingen)

This change was created by Thijs Alkemade, with small shuffling and
variable renaming by me.
List three security vulnerability fixes in the ChangeLog.
Thanks to Fabian Yamaguchi and Christian Wressnegger for finding
all of these, and thanks to Daniel Atallah for fixing.

The fixes were committed in 23cbfff68a0c, ef836278304b, and 68d6df7dc69c.
Fix conditional.

I think this would have incorrectly found a Connection: header in the
XML body. No idea what the harm is.
Add missing Entrust.net certificate for AIM
Add Ethan's AIM cert fix to ChangeLog.
Merge with no conflicts.
Update attribution for the four vulnerabilities discovered by Sourcefire VRT
Stop using g_uri_escape_string() to escape the URI before launching it.

This was wrong. Take this URL as an example:
https://developer.pidgin.im/search?q=brains&noquickjump=1&wiki=on

When escaped with g_uri_escape_string() it becomes:
https://developer.pidgin.im/search%3Fq%3Dbrains%26noquickjump%3D1%26wiki%3Don

?, = and & are replaced with %3F, %3D and %26 which means they are considered part of the path component rather than query args. I tested and I get 404s when launching that URL with Firefox, Google Chrome, and these manual commands: gnome-open, xdg-open, firefox, google-chrome.

Strangely I DON'T get a 404 when I launch the URL with Konqueror. The original unescaped URL loads. I consider this to be a bug in Konqueror. They would fail to load when launched with a URL that has a question mark as part of the path component because they would convert the remaining path into the query string.

So I ripped out uri_escaped and used uri in its place everywhere.

This bug never got released. We changed the behavior because someone reported
to us that this URL:
  http://example.org/$(xterm)
caused xterm to be executed on his system. Obviously that's bad if that
happens, but I don't think it's a bug in Pidgin. We're correctly escaping
all arguments that we pass to the browser command. If a system unescapes those
at some point and execs them, then that system is dangerously broken.

I tested this newest code with Firefox, Google Chrome, Konqueror, and the
manual commands gnome-open and xdg-open and they all work perfectly for me.
Bring back the URL escaping code, but use a better character whitelist.

I realized we can still percent-encode some characters to guard against
URLs containing $(xterm) causing xterm to start on horrendously broken
systems. We just need to be better about what characters we escape. So
I brought back Tomasz's code, added a few characters to the allowed list,
and we now use the escaped URI when starting ALL browsers. Works fine for me.
Add datallah's 4d139ce8f7ec to ChangeLog.
We'll be requesting a CVE for this one.
Add a line for datallah's cd529e1158d3.

There's already a line in here for setting the max http fetch size
(added to ChangeLog in 0b8bec51e84b), but we should mention the
CVE, too.
Fix a crash when hovering over an exceptionally long URL (4074 characters,
but it might be different for you) in a gtkimhtml widget (such as the IM
window).

This was reported on the support mailing list:
http://pidgin.im/pipermail/support/2013-March/012980.html
http://pidgin.im/pipermail/support/2013-March/012981.html

Repro steps:
1. "gdb pidgin"

2. "break gdk_x_error"
You'll probably need to type "y" to make breakpoint pending on future shared library load.  (Or you could run first then add the breakpoint.)

3. "run --sync"
--sync probably isn't actually necessary.  Theoretically it should make the backtrace more useful.  Like, maybe it could actually show the Pidgin calls that trigger the problem?  Or maybe the problem call starts from the gtk main loop, so there would never be Pidgin code in the backtrace?  It's also possible we don't pass our args to the right places to make --sync work.

4. "cont"
I hit the breakpoint at startup for some reason.  I've just been continuing past it.  Doesn't seem to affect anything.

5. Open an IM window.

6. Paste a long URL.

7. Mouse over the long URL.

8. The breakpoint is hit.

9. "bt"

#0  gdk_x_error (display=0x740e30, error=0x7fffffffbc20)
    at /build/buildd/gtk+2.0-2.24.13/gdk/x11/gdkmain-x11.c:458
#1  0x00007ffff73b94f6 in _XError () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#2  0x00007ffff73b6741 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#3  0x00007ffff73b6785 in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007ffff73b7378 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007ffff73b2d3d in XSync () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00007ffff73b2dcb in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#7  0x00007ffff73b9e2f in ?? () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#8  0x00007ffff7395d14 in XCreatePixmap () from /usr/lib/x86_64-linux-gnu/libX11.so.6
#9  0x00007ffff62bd0d2 in _gdk_pixmap_new (drawable=0x186ec60, width=width@entry=32774, height=25, depth=24,
    depth@entry=-1) at /build/buildd/gtk+2.0-2.24.13/gdk/x11/gdkpixmap-x11.c:175
#10 0x00007ffff6289617 in IA__gdk_pixmap_new (drawable=drawable@entry=0x186ec60, width=width@entry=32774,
    height=<optimized out>, depth=depth@entry=-1) at /build/buildd/gtk+2.0-2.24.13/gdk/gdkpixmap.c:249
#11 0x00007ffff6297036 in gdk_window_begin_implicit_paint (rect=0x7fffffffbed0, window=0x186ec60)
    at /build/buildd/gtk+2.0-2.24.13/gdk/gdkwindow.c:2779
#12 gdk_window_process_updates_internal (window=0x186ec60) at /build/buildd/gtk+2.0-2.24.13/gdk/gdkwindow.c:5574
#13 0x00007ffff6299201 in IA__gdk_window_process_all_updates ()
    at /build/buildd/gtk+2.0-2.24.13/gdk/gdkwindow.c:5696
#14 0x00007ffff6299269 in gdk_window_update_idle (data=<optimized out>)
    at /build/buildd/gtk+2.0-2.24.13/gdk/gdkwindow.c:5322
#15 0x00007ffff6276e77 in gdk_threads_dispatch (data=0x1a45c40) at /build/buildd/gtk+2.0-2.24.13/gdk/gdk.c:512
#16 0x00007ffff53d8ab5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#17 0x00007ffff53d8de8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#18 0x00007ffff53d91e2 in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#19 0x00007ffff663ec77 in IA__gtk_main () at /build/buildd/gtk+2.0-2.24.13/gtk/gtkmain.c:1271
#20 0x0000000000499950 in main (argc=1, argv=0x7fffffffe538) at gtkmain.c:933

This is the message it prints when it exits:
The program 'Pidgin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
  (Details: serial 14454 error_code 11 request_code 53 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

I think it's kinda lame that gdk/gtk/xlib/whatever barfs when we give it a
ridiculously wide pango layout, but whatever.  I'm assuming this problem is
gtkimhtml specific, and so I don't want to spend a whole lot of time fixing
it.  As an easy fix I want to just truncate the URL displayed in the tooltip
to 200 characters.

Here's an example URL that I used to trigger the crash:
http://www.example.com/?%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%30123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789%3012345678901234567890123456789012345678901234567890123456789012345678
Fix a crash when using hidden conv window (for persistent chats) and a single compilation error
IRC: implement support for required args checking in message parser
Fill in real CVE identifiers assigned to us by our contact at Red Hat.

I appreciate that they're available to assist us.
Clean merge.