Fix Dropbox case-conflict asymmetry.

The problem was that Dropbox, a case-insensitive service, treats
all filenames as all lowercase. This is a big problem for Onitu
and other services who don't have this constraint: we don't want
to trigger new transfers and detections for a file that is only
the same, but renamed against our will just because of one
service's limitations.

To fix it, we established in the Dropbox driver a
"virtual file mapping" system that permits Onitu to know, in case
of a conflict on Dropbox, what is the matching file on Onitu side.
Dropbox will have its own name for the duplicate created out of the
case conflict, and Onitu will keep the "normal" filename on its side.
Modifications of the file to, or from, Dropbox are transferred with
the good filename, depending on which side we're on.

It is a complex solution for a simple problem, but there's no real
good way to handle it, except not creating case conflicts. User
should be strongly advised about this problem, since this is a
rather confusing system (the same file gets two different names
on each side). To promote this idea, I put a lot of warnings
in each piece of code dealing with case conflicts in order to get
user's attention.

- As a consequence, we don't overwrite files on Dropbox anymore

- Change the detection system as the old one we used is deprecated

- Some refactoring
Randomize the test root folder for Dropbox