Add External SIP Provider bridging capability

Superseded by !685 (merged)

E.g. If a cloud provider offers SIP Gateways to the PSTN, this new feature allows the B2BUA to use accounts on this external SIP server to bridge calls to telephone numbers.

This bridge does not attempt to hide itself by overriding the From header.

• Rewrite cli info command with jsoncpp
  • Choose between jsoncpp, jansson, and cJSON (it's jsoncpp. Per @smorlat's advice)
• Instanciate a CommandLineInterface along with the B2BUA
• Add name to providers for display
• LOGF on bad config
• Add warning that handleCommand isn't threadsafe
• Add SIP_BRIDGE command description in flexisip_cli.py
• Make the CI test suite run on Sanitizer
• Fix memory leaks in B2BUA tests
  • Fix indirect leaks in "SDES to ZRTP call" (Lead: circular shared_ptr references. Suspects: LinphonePrivate::MediaSession, LinphonePrivate::Sal, LinphonePrivate::SalMediaDescription, std::unordered_map, linphone::Call, linphone::Account) leaked call params
• Use JSON for external providers configuration
• Fix passing of MBEDTLS_FATAL_WARNINGS to mbedtls
• Rebuild docker images without ffmpeg and v4l where applicable
• Add missing 'b2bua' option to flexisip's --server options
• Indicate default config location in --help
• Don't use f-strings in flexisip_cli.py (not available before python 3.6)
• Support one-sided video call? (option to drop video in the Provider JSON?) Tests show that the B2BUA allows one participant to have video while the other has not.

Best effort:

• Refactor the CLI handling logic to avoid splitting commands between their C++ implementation and their documentation in the Python CLI socket client.

Notes:

Integration tests showed a need for a way to override SDP negotiation: The outgoing bridge<->provider call uses the call params from the incoming user<->bridge call, and therefore forwards capabilities like encryption or AVPF to the external provider which can result in a 488 Not Acceptable when unsupported.

After fixing the segfault on 488, liblinphone is perfectly able to fallback to AVP when AVPF is not supported. The B2BUA is then able to bridge an APVF call on one side with an AVP call on the other. I don't see a need for this feature anymore.