ews: add 4th autodiscover type

The 3rd type introduced to fix problems with Office 365 in

    commit 0ba825ca063e3d94487ec518e9a1c3f5a722dd1c

was based on trial & error. It seems that sending a POST request to a
http:// autodiscover URL does not work for all accounts:

    https://sourceforge.net/p/sipe/discussion/688534/thread/d21ebf11/

After studying another M$ document it turns out that we are allowed to
also send a GET request to such an URL and will then receive a redirect
response.

I tested that this works for at least 2 different Office 365 accounts.
GET seems to be accepted for Office 365 accounts for which POST was also
working. So we now try GET first and only then we try POST.
update files in preparation for next release
configure: add option for libpurple 3

Build can now be configured with --enable-purple=3 to enable compilation
against libpurple 3 and GStreamer 1.0.
conference: use a single counter for CCCP request IDs

[MS-CONFPRO] 2.2.2 says requestId must be a non-negative integer unique
among all requests from the sender. Thus, it's enough, and likely even
more correct, for sipe_core_private to have a single cccp_request_id
counter instead of a separate copy in each sip_session.
conference: refactor CCCP request creation

Moved repeating parts of the code into cccp_request().
conference: use cccp_request() in sipe_conf_add()
conference: use cccp_request() in sipe_conf_create()
conference: use cccp_request() in sipe_conf_modify_user_role()
conference: use cccp_request() in sipe_core_chat_modify_lock()
conference: use cccp_request() in sipe_conf_delete_user()
conference: obtain a list of enabled MCU types

Multipoint control unit types represent conferencing capabilities
enabled on the server (text chat, audio, video, etc.).
conference: refactor CCCP request creation II

Also sip_transport_* requests can be moved to cccp_request(), resulting
in further reduction of duplicate code.
conference: use only supported MCUs in addConference

When creating a conference, allocate only those MCU-types that we know
are supported by the server, i.e. received in a response to our
'getConferencingCapabilities' request.

This fixes occasional 'mcuTypeNotAvailable' error responses when Sipe
wanted to use audio-video conferencing on a server where this option was
disabled.
media: notification when conference calls not supported