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 property to disable deletion of empty chatrooms
Enable compiler option '-Wunused-parameter'
Fixed possible null pointer exception in Java wrapper for Android
Update copyright notice in wrapper files

Move all the pipe related code from the historical ortp functions to bctbx

More work on documentation + modified JAVA wrapper to ensure all returned arrays are never null even if the C API says maybenil

Move license to GPLv3, update version number to 4.3.0.

Fix no audio issue - because StunClient was corrupting localMediaDescription when no STUN discovery was actually made.