Add option for dual stack IPv4&IPv6 account config

[sauwming]

To close #2146 .

Add the following options in pjsua for SIP/media account config:

/**
 * Specify how IPv6 transport should be used in account config.
 * IP version preference only applies for outgoing direction, for incoming
 * direction, we will check the corresponding message/offer and match it.
 */
typedef enum pjsua_ipv6_use
{
    /* IPv6 is not used. */
    PJSUA_IPV6_DISABLED,
    /* IPv6 is enabled. */
    PJSUA_IPV6_ENABLED = 1,
    PJSUA_IPV6_ENABLED_NO_PREFERENCE = 1,
    /* IPv6 is enabled, but IPv4 is preferable.*/
    PJSUA_IPV6_ENABLED_PREFER_IPV4,
    /*IPv6 is enabled and preferable. */
    PJSUA_IPV6_ENABLED_PREFER_IPV6,
    /* Only IPv6 is enabled, IPv4 will not be used. */
    PJSUA_IPV6_ENABLED_USE_IPV6_ONLY
} pjsua_ipv6_use;

And add field pjsua_acc_config.ipv6_sip_use in addition to the already existing ipv6_media_use.

For backward compatibility and interoperability reasons, the default settings of the fields are:

• ipv6_sip_use: PJSUA_IPV6_ENABLED_NO_PREFERENCE, which means that for SIP transport, it will depend on the address resolution result returned by the OS (pj_getaddrinfo()) or by the resolver. Note that this is the current behavior.
• ipv6_media_use: PJSUA_IPV6_ENABLED_PREFER_IPV4, which means that outgoing offer will still use IPv4, but it's capable of receiving IPv6 media offer without any additional modification. For interoperability reason, IPv4 preference is recommended since not all endpoints support IPv6.

Note: IPv6 usage setting may not apply for ICE media transport, depending on STUN configuration. This behavior is observable before this PR. We may need to modify ICE media transport IPv6 usage spec in the future, which is beyond the scope of this PR.

[nanangizz]

• perhaps this can be categorized as criteria, so it can be moved to be inside union u?
• also, term config is perhaps too broad and currently the criteria is an enum (while config is more like a struct that can be expanded in the future), so what if using term like ip_ver instead?

[nanangizz]

just a very minor proposal below.

[sauwming]

Final testing before merging.

Test environment: dual stack Mac OS

SIP registration tests:

1. Scenario 1: normal registration with default setting, no IPv6 SIP transports created, getaddrinfo() returns IPv6 first
   Pre patch: Initial reg will fail to get contact source port (due to no IPv6 transport)
   normal_pre_patch.txt
   Post patch: No issue (since there is fallback mechanism, if IPv6 fails use IPv4, and vice versa)
   normal_after_patch.txt

2. Scenario 2: normal registration + IPv6 SIP transports
   NO_PREFERENCE: getaddrinfo() returns IPv6 first, IPv6 will be used
   no_pref_ipv6.txt
   NO_PREFERENCE: getaddrinfo() returns IPv4 first, IPv4 will be used
   no_pref_ipv4.txt
   PREF_IPV4: getaddrinfo() returns IPv4 first, IPv4 will be used
   prefer_ipv4.txt
   PREF_IPV6: getaddrinfo() returns IPv4 first, IPv6 will be used
   prefer_ipv6.txt

3. Scenario 2: normal registration + IPv6 SIP transports, use nameserver
   NO_PREF, PREF_IPV6: initial reg use IPv4 Contact and Via (note that contact_use_src_port doesn't work if nameserver is configured), nameserver returns IPv6 as priority, so reg sent using IPv6 transport, then contact update will correct the addresses to IPv6
   pref_ipv6_ns.txt
   PREF_IPV4: nameserver returns IPv6 as priority, reg sent using IPv4 transport
   pref_ipv4_ns.txt

Media tests:

1. Caller pref IPv6 vs callee pref IPv4. Callee accepts IPv6 offer and media is successfully established.
   caller_pref_ipv6.txt
   callee_pref_ipv4.txt
2. Caller pref IPv6 vs callee pref IPv4, using TLS and SRTP. Callee accepts IPv6 offer and SRTP media is successfully established.
   caller_pref_ipv6_tls_srtp.txt