when initiating a call;
- from header
- account
These 2 parameters are dependent from each other which makes tricky for
the core to know exactly which account to use and the correct from
address.
In most scenarios, the from address is the account's identity address
but it is not always the case such as in the case of a direct call.
Moreover, the account cannot be always deduced in a straightforward
matter such as if the core has no default account (but it is registered
with one or more accounts) and the call parameters have not set one.

The algorithm for choosing an account is the following:
1) search in the call parameters
2) get the default account
3) look up for the best guessed account based on the from (if known) or
   to address

The algorithm for known the from address is the following:
1) look for the from header in the call parameters
2) look up for the identity address of the account (if known)
3) get the core primary account

Set Ik SDP attribute based on the account used for a call

Use account set in the call parameters before retrieving the NAT policy.
It may happen that a call session is buuild without passing an account
and in such a case, the SDK will do its best to get one

  - Add callback to notify the application that a participant has changed role in the conference
  - Take into account role when creating the list of participant informations of a conference
  - Give priority to the conference information stored in the database over that cached in the call log object
  - When a participant is added, give the application a pointer to it with all the informations up to date
  - In the event of a full state, reduce the number of database accesses by updating the conference information in the callback onFullStateReceived. Previously, for every participant added a DB access was required in order to update the conference information

Tests:
  - Add verification of role and sequence id of every participant info in the conference information in the call logs and conference information
  - add helper functions to ease checking of conference informations

video conference factory if the core is used as a conference server

Replace usage of ProxyConfiguration with Account in classes Call,
CallSession and MediaSession

- a RecvOnly audio stream with content DTX and the participant label for each participant of the conference. A secured conference will have N audio streams (1 sendrecv for the local participant and N-1 recvonly for the other participants)
- add security level to the conference parameters
- pass security level information to the conference server
- add encryption information to the database table storing conferences
- pass security level down to MSAudioConference and MSVideoConference objects
- add extra video stream for encrypted conference in active speaker layout

Fixed find friend by phone number when number has international prefix but no '+' + improved performances a bit

More improvements & fixes for AccountCreator & FlexiAPI + add user-agent header to FlexiAPI HTTP requests

- Remove reason field from LinphoneToneDescription
- Store tones by ID
- choose tone based on the reason when a call ends

Fix crash when an account is deleted during a call, fix bad Contact header for out of account calls, fix regression in telephone-event payload type number selection.

- Delete classes IdentityAddress and ConferenceAddress
- Make Address a derived class of HybridObject
- Use smart pointer for objects of Address type whenever they need to be handled by the applications

Fixed bodyless friend list initial subscribe not being sent if proxy config takes too much time to register

Allow building without libxml2 and sqlite3, to minimize binary size. This drops features (friendlist storage, presence).

Add linphone_core_create_nat_policy_from_ref to be called to create a NatPolicy object from its reference in the rc file
The value of the nat_policy_ref may be the reference of the nat policy or the name if the section in the rc file

Add private Utf8 setter and getter for conference subject, ics uid and description
Clone conference information before updating or cancelling a conference
Parse ICS as UTF8 string to ensure non-ASCII characters are correctly decoded under the Windows environment

Following a restart of the conference server, conference that were created earlier on can onlmy be found in the database. In such a case, the object LocalConference must be recreated from scratch once the server receives an INVITE for one of them.
There are 2 possible scenarios:
- a participant wants to join the conference: time boundary is set to 0 0 (in the SDP: t=0 0) -> conference recreated using the conference information stored in the database
- an admin wants to update the conference: time boundary is not 0 0 -> conference recreated using the SalCallOp informations. Note that if the list of participants is empty, the conference will be cancelled

Do not create streams if the invite session is only used to create a conference on the server to prevent a ms2 graph being created