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.
OK, I agree it's handier in the day-to-day life, I'm just a bit worried about portability (but it seems everyone's wanna be GCC anyway so maybe it's all OK), and, heh, NIH? :)  (just kidding on that last point, unless it grows out of hands)
If we do that (and sounds like we will) I just want to make sure that we use `-fvisibility=hidden` *only* if `GEANY_API` *actually* expands to the same model.  E.g. I wouldn't want to use `-fvisibility=hidden` with a compiler that supports the flag but don't define `__GNUC__` to >= 4 (or whatever is the condition we have), nor that don't understand `__attribute__((visibility))` (or whatever is the flag).  I just want to make sure we won't risk in some case of building with *all* symbols hidden.  Better leak all symbols than not export any, right? :)

But, on that subject, shouldn't we have it expand to `__declspec(dllimport)` when the header is used by plugins?  If that's useful (I guess it has some use if it's used everywhere?), we then should have `GEANY_API` tags in the headers and not in the sources (or both but that's a bit redundant).

> […] we could fall-back to adding -Wl,--export-dynamic` […]

No need, it's a library and AFAIK only Windows don't export everything by default in those.

> (the format is not the same as for ELF targets, but I guess libtool abstracts that?)

I didn't test but I would think so, as Libtool does provide the abstraction layer.