Implementing new architecture in msn-prpl

Split SLP modules:

The first thing needed was to move SLP code to where it belongs. 

Every high level calls like requesting a msn transfer, an user display and stuff to the upper layer of the stack (slp.[ch]) this was easy because most of the SLP code was there so the file needed a cleanup.

Every SLP protocol decode and management, like sending acks, an 200OK after the invite and stuff, to the SlpCall module, most of that code was on slp.c and some other on slplink.

Every interaction with link layers, splitting the SlpMessage in Parts in SlpLink module.

Most of this changes were mostly cut-paste changes, still a lot of functions needed to be exported as public so the other modules can use them, it was not so painful.

Get MsnMessage out of here!

Since the code was designed to be used to transfer data using the Switchboard, all the code was populated with MsnMessages which is a representation of the MSG SB command.that is used to send the SlpMessages to the SB server. Since I wanted to get this stack agnostic of link layer it was needed to get the MsnMessage out of the way. It was hard since this object was used as the core of some of the functionality, most of the cases it was replaced by a SlpMessage.

This change was really big because it imply get away every SB code  from the SLP stack and abstract it in some way that can be used any of the link layers.

Msn-prpl Slp Refactor

I have been chosen to refactor the SLP module of the MSN-prpl as my Google Summer of Code work. This module have not been touched since ages, if you read it closely it's clear that it's a hack over a hack with some primitive and old structure mostly lost by the hacks that were added over the years.

As the first part of my work I have somehow re-designed the SLP stack as shown in the SlpArchitecture page, this stack is mostly based on the original structure. I will not elaborate a lot here about the modules because that documentation must be done on the wiki page. ;-) Still I want to explain a little the major changes I did to the original stack.

Msn have different ways to do p2p, libpurple now support both, Switchboard and DirectConnection. The first one is the one that have been always supported where we send the binary data to the Switchboard Server and it redirect it to the buddy client. The recently added DirectConnection support does open a socket on both clients so they can communicate "directly" so the transfer is really faster this way.

To be able to use the same SLP code to manage both types of p2p I have added a Conn layer which aims to abstract the Switchboard(SB) or DirectConn(DC) link. They both manages just the SlpMessageParts and send them outside.

Both SB and DC have some data size restriction, when the binary data that needs to be sent is bigger than the link limit, they must be split in different messages. This is the reason of the creation of the SlpMessageParts which is the fragmented representation of a SlpMessage that can be sent to the link layer down to the stack allowing the upper modules to manage a SlpMessage just as single message without noticing if it's big or small, that is abstracting the need to split messages to the upper layers on the stack.

This is basically why I have done the changes in the architecture, I hope this new architecture will be extensible and easy to maintain.