W32: Remove custom libgedit.a import library

Since we have a real, shared libgedit.dll, we can have a real libgedit.dll.a
import library.

https://bugzilla.gnome.org/show_bug.cgi?id=727663
Plugins need code from shared libgedit, so link them to it

https://bugzilla.gnome.org/show_bug.cgi?id=727663
W32: Override libtool internal variables to produce a delay-load import library

We remove --out-implib, add --output-def (where needed), and add extra call
to dlltool to generate delay-load import library (name's the same as normal
import library, so tools/applications won't notice the change).
When application is linked to libgedit via such import library, the DLL is
only loaded when first function from it is called. This gives us time to
influence W32 runtime linker.

https://bugzilla.gnome.org/show_bug.cgi?id=727663
W32: load libgedit.dll at runtime

Since libgedit is linked as delay-loaded DLL, it's still not loaded when
main() is called. Before we call functions from it, we must locate
libgedit.dll and load it (otherwise, if it's not in PATH (which is how it
should be!), calling its functions will crash the program).
As comments indicate, the use of g_module_open() is not really necessary,
but, given the circumstances, it is convenient and clean.

https://bugzilla.gnome.org/show_bug.cgi?id=727663
W32: Fix .pc file LDFLAGS (assuming libgedit is in <prefix>/lib/gedit)

https://bugzilla.gnome.org/show_bug.cgi?id=727663
W32: Move installed libgedit.dll into appropriate dir

https://bugzilla.gnome.org/show_bug.cgi?id=727663