Drag n' drop API's are implemented in GUI widget libraries, which are built on top of something else (on linux, Xlib).
Is targetting to Qt (KDE), Gtk (Gnome) and XFC(XFCE) enough ?
Qt and Gtk are distinct GUI libraries. If you write a GUI application (which is the only context in which drag n' drop makes sense), you choose a library, not two or three of them. I've never heard of anyone creating and maintaining both a Qt and Gtk version of something because there would be very little point: they are portable to the same set of platforms. If you have a Gtk version, it will probably run on systems that run Qt, and vice versa.
Qt and Gtk applications both will run without issue under any linux DE. They are not limited to GNOME and KDE. If you use KDE, you probably have a few Gtk apps on your desktop anyway. If you use GNOME, you might have a few Qt ones. That's how a software stack works.
While it is possible to write GUI applications using only Xlib, it's pretty unusual1 for a number of reasons; it's unportable, it defeats the purpose of modular hierarchies in software design, etc.
Part of the point of the more portable, higher level libraries (Gtk, Qt) is they abstract away the lower level, more platform specific ones such as Xlib.
Should one learn the implementation of clipboard first
I doubt the Xlib clipboard has anything to do with it, but in any case, again, there's no need to learn much about Xlib if you want write GUI applications for linux. You start with one of the higher level libraries.
If you want an introduction to the drag n' drop API for Gtk, with a quick nod to the Xlib facilities it is built upon (on systems that use Xlib), have a look here.
You've said you are interested in universalizing a feature such as "dragging to taskbar to restore window before drop". This kind of behaviour is indeed the realm of the DE or window manager (WM -- all DE's require a WM, but WM's do not require DE's), whereas the actual DnD mechanism is lower down. It's behaviour that just involves a particular kind of use case for the mechanism. However, because it is in the higher realm of the DE, it is outside the realm of the individual application. If you are writing a GUI app, this is not something you should be concerned with at all.
Linux is unlike Windows in that its desktop interfaces are heterogeneous; part of what that means is that universalizing high level behaviour like that is intentionally problematic (no one wants one ring to bind them all). It is no more appropriate to be concerned about heterogeneous window mechanics at the application level than it is to be concerned about exactly how the borders and titlebars look; the DE/WM take care of this to create an integrated look and feel that is configured by the user for the entire desktop. It is not appropriate or user friendly for individual applications to try and wrestle this control away from the end user and DE to behave in a way you want to see windows work on your choice of desktop. Because I want to use your app does not mean I also want to live by your rules WRT window behaviour. Applications don't have to be involved in that, and for the most part, should not. There is no good reason to rebel against this model; it may be distasteful to you, but it is presumably appreciated by the users of the operating system you are trying to target. Apple users would resent application programmers trying to make their desktop act like Windows, Windows users would probably not appreciate application programmers trying to make their desktop work like KDE, etc.
That said, there's nothing wrong with some kind of add-on "gestures" library -- although again, this seems like something more appropriate to implement within a DE, and some of them do have configurable gestures. You may be interested in extended window manager hints, which is an attempt to create a high level universal protocol to assist applications in invoking certain kinds of behaviour (a universal protocol would be necessary just to identify a taskbar in this context). Note that EWMH compliance is of course voluntary and will vary from WM to WM.
1. It's also possible to write GUI applications by starting with bare metal -- you create your own operating system and go from there. But again, that is not the orthodox approach.