Gsoc 2014 message carbons

Please review the message carbons implementation.
@shambhuprasad58, that's better, but essentially you can go all out and refactor all the way down! That is: you can now take the nested statement inside `classify_packet/4` and rename the particular operations that you're doing. This will go from:
```erlang
case xml:get_attr_s(<<"type">>, Attrs) == <<"chat">> andalso 
		xml:get_subtag(Packet, <<"private">>) == false andalso
                     xml:get_subtag(Packet, <<"no-copy">>) == false andalso
```
to maybe something like:
```erlang
case is_chat(Packet) of 
   false -> ignore;
   true -> classify_chat_packet(Jid, To, Packet)
end. 
```
And then you'd write `clasify_chat_packet/3` to handle the various checks. Try to make the code as readable as possible. 
*  Think _how much you'd need to change_ if the XEP changed and the handling strategy would need to be modified. 
*  Perhaps my above refactoring is no good (buggy, slow, whatever).
*  Perhaps running the message through a list of funs of type `fun((JID,To,Packet)->classification())`\*, and returning `ignore` on the first `ignore`, or `forward` if all the checks pass would be a more functional way of handling the topic.
\*Where `-type classification() :: 'ignore' | 'forward'.`

Also: **please don't use strings as a return type**. If you're dealing with actual text, then stick to `<<"binary strings">>`, and if you're modeling, then atoms are idiomatic default. Your `classify_packet` function should return the atoms `ignore` or `forward`, and not the strings `"ignore"`, `"forward"`.

Go wild, take the opportunity to learn and experiment!