They are cached in AudioRtpFactory, but may be replaced in
AudioSrtpSession. Therefore, whenever we reinitialize these contexts
we must update the cached values in audiortpfactory. In addition, since
they will outlive a given AudioSrtpSession, they must NOT be deleted in
AudioSrtpSession's destructor but rather in AudioRtpFactory's.

99 % of these are just whitespace changes. Some unnecessary includes
removed as well

sflphone-common -> daemon
sflphone-client-gnome -> gnome
sflphone-client-kde -> kde
sflphone-plugins -> plugins

AudioRtpFactory: return cached type of rtp session. The rtp session can have disappeared if the call was put on hold

Now AudioZrtpSession and AudioSymmetricRtpSession are derived from it, and AudioSrtpSession is derived from AudioSymmetricRtpSession
AudioRtpSession class keeps a pointer to the RTPDataQueue and Thread casts of the 2 specialized classes to access a few, because AudioRtpSession doesn't derive from RTPDataQueue or Thread directly.

Now AudioZrtpSession and AudioSymmetricRtpSession are derived from it, and AudioSrtpSession is derived from AudioSymmetricRtpSession
AudioRtpSession class keeps a pointer to the RTPDataQueue and Thread casts of the 2 specialized classes to access a few, because AudioRtpSession doesn't derive from RTPDataQueue or Thread directly.

In AudioRtpFactory, we now have a registerAccount method that deals with
Account objects and another to deal with SIPAccount objects.

	Update audio codec in call_on_media_update()