IWD doesn't accept or export raw IEs on the DBus interface, instead it
takes individual parameter values and only a subset of all the ones that
the IEs contain.  Make the connman-specific Client class build the IE
locally from an abstract parameters struct.  For now the struct contains
the values that source-app.cpp and sink-app.cpp use, if they need to
indicate support for any of the extended WFD capabilities or other
parameters, this struct will have to be extended too.

This might also be a step in supporting Miracast over Ethernet (MICE?)
if ever needed -- I think this is the name used for the R2-specific
connection method where parameters are exposed as mDNS records.

In order to support other clients than Connman, rename P2P::Client to
P2P::ConnmanClient and P2P::Peer to P2P::ConnmanPeer while making them
subclasses of new base clases P2P::Client and P2P::Peer.  Those base
classes are abstract and only have what is expected to be common between
Connman and IWD.

Make the struct global within the P2P namespace so it can be used in the
Peer class as a utility struct.

Similar to the DBus-based Connman client add a DBus-based IWD client for
managing peer discovery, connection/disconnection and P2P service
registation using the IWD DBus-service.

To avoid forcing the source/sink apps to select between one client or
another, add the MultiClient class, implementing P2P::Client, so that
it can be a drop-in replacement of ConnmanClient that does the right
thing depending on which of the two services are available on DBus.
Under the hood it hold objects of both ConnmandClient and IWDClient and
whichever detects its corresponding daemon is available for use,
forwards any callbacks through MultiClient up to the app.