Linkage Cleanup

This PR cleans up the symbols exported by Geany and makes linking plugins more robust by allowing them to link to the symbols purposefully exported from the new `libgeany`. The end result is that the only symbols exported are the ones which are part of the plugin API and there is no longer any need for the special macro/function pointer stuff which was useful before the GtkBuilder (`-Wl,--export-dynamic`) changes made it pointless.

It doesn't export any global variables because I didn't find any problem without, but according to @kugel- both the GeanyPy plugin and his Gobject-Introspection/PluginAPI stuff needs them, so we'll probably need to export those as well.

This PR breaks the ABI because it removes all the `GeanyFunctions` structures, though it leaves the `GeanyFunctions` type opaquely so it won't break all plugins using `GeanyFunctions *geany_functions;` at the start of their plugin code. Any plugin that does not poke into `geany_functions` should be safe from source code breakage. The changes also exposed a few bugs in a couple Geany-Plugins, although I think @b4n already fixed a number of them. The ABI break is not strictly required, so if we're not going to break the ABI for anything else anyway, it might be better to do something like @kugel-'s PR #355 and put the old structures stuff in a separate C file we can delete later when we break the ABI.

Only Autotools build system was updated, TODO is the makefile.win32 files and Waf. The codegen stuff in this PR could easily be done in Waf with Python, there's some code we can copy in the commits, that was eventually removed in favour of more portable and mysterious shell one-liner in f4a0b09.

Along with PR #351 (already merged) the plugin API declarations/symbol leakage is pretty much gone.
I agree with @codebrainz and @elextr, this is way more convinient that hand-maintaining a export file (or relying on a possibly fragile script). The worst case is that all symbols are exported (i.e. status quo, not a big deal), but it still allows us to catch bad plugins in the most common case. 

Windows only exports decorated functions anyway regardless of -fvisibility, but it can also work via a export file (the format is not the same as for ELF targets, but I guess libtool abstracts that?)