Generation of Vala .vapi files for Rhythmbox version 0.5

First comment:

Generating a single namespace in one shot is more contorted than generating two separate ones and concat them afterwards into one .vapi (but leaving them as separate namespaces). With a single namespace Vapigen explicitly exposes all "self" arguments on all of the objects as the introspection can't resolve the cnames of types and the names given to the objects for generation.

So this patch is my first stab at integration into autotools build + install. Builds ok with and without Vala enabled. Generated VAPI and related .deps are installed into appropriate locations.

Notes:

(0) Patch is against 0.13 - previous mentioned patch to change invalid entry type to (0) from (-1) is included.

(1) There is a dependency on the librhythmbox-core.la from the Vala bindings - as such I separated out the Python and Vala subdirs at the top level to allow building bindings/python _before_ shell, and bindings/vala _after_ shell.

This is due to the vala introspection needing the library to generate interfaces correctly - just supplying the headers doesn't seem to be sufficient (problem seen with GLib.TypeInterface(s)).

I know this is nasty, and will have to go back to Michal's initial patch to see how he generated something useful to link against and change to use that.

(2) Running a "make dist" fails if the target vapi file has not been generated yet. Looks like the sample vala plugin is attempting to compile itself when a make dist is done. make dist _does_ work if the tree has already been built once.

(3) Almost certainly the objects and methods need testing - I haven't exhaustively done so. I did check some of shell, rhythmdb, metadata and query stuff by building external apps against the installed results (headers + pc + vapi) and had success running them.

(4) I've bumped up the minimum Vala version to 0.8.0 due to needed bugfixes of Vala tools - however when the version used is < 0.8.0 the error message is "Vala wasn't found". I'm far from an autoconf expert, so I've left it like that for now.

(5) Not found a sensible way to switch on and off some method visibility on some objects due to the naming issues (notably RhythmDB and RhythmDBEntryType)

(6) The autogeneration showed me the extra bool (in 0.13.0) that has appeared on Shell.new to determine if Rhythmbox was autostarted. That's a good sign it's doing what was intended.

(7) There isn't 100% coverage of the exposed headers of course.

TODO: 

Look deeper into why introspection needs a library and not just the header files

Fix dependancy on shared object by having a linkable object built in the local dir if it is completely necessary.

Fix the "make dist" to work without vapi being present (this bug was already present)

Fix detection of too old Vala version to give appropriate error message

Testing, testing, tea and testing

