Merge Dropbox driver

The driver is done for the most of it, and already works for casual use.

However it isn't perfect yet : 

- Deletion detection works only if it's performed while Onitu is running and checking. Onitu won't detect deletions that happen while it's down. That's because of Dropbox use of delta cursors in order to know what changes it musts notify you. Entries cannot (yet) store data in the database (e.g., the last cursor used), so everytime we run Onitu, the first delta is always done without cursor, only doing a general listing of what's in Onitu's root, without notifying deleted files. This problem will be resolved when #65 is finished.

- Moves aren't strictly speaking detected by the Dropbox driver. The driver is actually notified when a file gets deleted and when a new one is created, hence when a file gets renamed on Dropbox, Onitu will delete the local file, and then receive the notification of the new file on Dropbox (the renamed one), triggering the re-download of the file, which is kind of the same thing. This is obviously sub-optimal comparing to correctly detecting the move, however I studied this problem for good, and I don't think we'll ever be able to detect moves (with the current API, that said). Dropbox hasn't any kind of move modification / notification, and when the file gets deleted and recreated, Dropbox loses some metadata on the old file (like its client modification time and its size). It is at the moment impossible to tell with 100% assurance a new file is the new version of a deleted one. BTW and IIRC, even the official Dropbox client goes through all this process of deletion/recreation.

- A remaining issue is the problem of Dropbox case-insensitiveness that we don't address at all (see #73 ). For the moment we assume the user knows Dropbox is case-insensitive and should always use files with different file names. For the moment, having two files with the same name but conflicting cases creates asymmetry between Onitu and Dropbox (the two files are on Onitu, the last uploaded one overwrites the first one on Dropbox). An issue has been opened on the subject ( #73 ), but I don't really see *the* good solution for us. For example, in such a case the official Dropbox client renames the local file with its name + '(Case Conflict)' and doesn't upload it until the name is changed to a really unique one. Maybe we should do that.

Same description as above, a bit weird :) .