Allow peer-specific sending and receiving of remote signals

For file transfers and possibly other use cases, it is important to know
which peer has received a specific signal, and to allow sending remote
signals only through a particular peer rather than multicasting to all connected
clients.

For this reason, we now treat attached signals/slots specially if their first
argument is a PeerPtr (a typedef for Peer *):

* An attached slot will have a pointer to the peer which received the signal in
  its first argument
* An attached signal on the core side will be relayed only through the peer that
  is given as the first argument (and the receiving slot will have a pointer to
  the client-side peer in this argument)
* The peer argument for an attached signal on the client side will be ignored,
  as clients only have one peer anyway
Basic infrastructure for file transfers

This introduces the Transfer class as well as TransferManager and the
specialized versions for client and core. It also adds the needed accessors
in Client and CoreSession as well as the SyncableObject stuff to make it all
work together.

To make something happen, a Transfer needs to be created on the core side with
the appropriate attributes; it needs then to be synchronized and handed over
to CoreTransferManager::addTransfer(). This will trigger the creation of the
appropriate Transfer object on the client side, adding this to the
ClientTransferManager as soon as synchronization is complete (meaning, the
transferAdded() signal will be fired with a fully synchronized Transfer object).

Note that the list of transfers is not synchronized (yet?), so there won't be a
transfer history on re-sync.
Make the PeerPtr trick work with sync calls as well

The mechanics for replacing a PeerPtr as first argument by the
sending peer (and using it as a filter for the other direction)
are already in place; with just some tweaks we can also make it
work for sync calls in addition to RPC calls, which allows for
selectively calling methods in your sync partner.
Delete the TransferManager on disconnect

Makes sense, doesn't it...?
Transfer needs a nick attribute

So we can show who sent us a file, which may be a nice thing to know.
Add missing accessors to TransferManager

Nice to be able to access the list of transfers.
Make the Transfer::accept() and ::reject() machinery work

This adds the necessary stuff to be able to accept/reject a transfer
on the client side, syncing it on the core side and setting the
necessary signals. The core also receives a PeerPtr, so it can keep
track of which peer actually accepted the transfer.
Add a very rudimentary UI for accepting a transfer

This is just a temporary solution for being able to accept or
reject an incoming transfer. We just display a little dialog and offer
a way to specify a path for saving.

This lacks many features and will be replaced by a proper transfer manager
widget later.
Add handler for DCC-SEND

This adds a basic handler for incoming DCC-SEND requests. Note that not
all features are supported yet, there are no settings and no way to disable
it. Also, the EventStringifier hasn't been adapted yet, so there will be
a warning about an unknown event in the status buffer...
Refactor the transfer stuff

Well, sometimes refactorings come sooner than usual. While thinking
about the next steps, I decided to handle the actual transfer logic
inside Transfer rather than TransferManager - now that we can have
selective (peer-based) sync calls as well, that makes more sense than
outsourcing that to TransferManager. Thus, it now makes lots of sense
to have ClientTransfer and CoreTransfer, as the logic will be quite
different.

I also took the opportunity to clean up the accessors and make them
safer; you can now get a non-const CoreTransfer pointer, for example,
but still only a const ClientTransfer pointer.

Also, some useful signals have been added.
MainWin should get a ClientTransfer pointer

Just listening to the appropriate signal makes more sense if we
actually want to use client-side functions later.
First working version of DCC Receive

This finally allows accepting a file via DCC and storing it on the client side.
Note that this is still a very basic implementation, in particular missing

  * Proper status messages (still claiming to receive unknown CTCP, for example)
  * Proper error handling
  * Proper testing
  * Any kind of configuration
  * Any kind of UI besides the simple dialog on incoming files
  * No queuing or any form of transfer management
  * Things like DCC REVERSE

However, it serves as a nice proof-of-concept for the general approach of
passing data directly to a particular client using the usual sync mechanism
(i.e. no special protocol support or additional connections needed). First
client to accept the transfer will get the file.

Note that the *core* is the one handling the DCC connection itself, so things
like port forwarding or firewall support need to be done core-side.
Remove unused slots
Make DCC support opt-in for now

As support for DCC is unfinished, untested and potentially dangerous
(i.e. one could spam your desktop with millions of dialog boxes), disable
it by default.

People really wanting to play around with this may start the core
with --enable-experimental-dcc, but you have been warned.