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.
On 27 October 2014 12:18, Matthew Brush <notifications@github.com> wrote:

> In m4/geany-lib.m4:
>
> > @@ -0,0 +1,37 @@
> > +AC_DEFUN([GEANY_LIB_INIT],
> > +[
> > +
> > +dnl In the future, if we want to use libtool/library versioning, we can
> > +dnl set these variables accordingly. For now its the same as if not specified (0:0:0)
> > +	libgeany_current=0
> > +	libgeany_revision=0
> > +	libgeany_age=0
> > +
> > +dnl Try and see if we can use -fvisibility compiler option and GCC`s
> > +dnl `__attribute__((visibility(...)))` extension and use it if so.
>
> I'd rather keep the "annotations" (ie. GEANY_API_SYMBOL) right there next
> to source code and Doxygen comments,
>
​Definitely keep this, if its a problem on some platform just configure the
macro empty, and export everything as Matthew says.​



> but we could move it back out to a separate file that we keep in-sync. I
> would think at least any GCC's and Clangs and their commercial counterparts
> could support this, if not, we could fall-back to adding
> -Wl,--export-dynamic` to the linker flags to leave it same as last
> release.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/geany/geany/pull/358/files#r19385903>.
>