QueryMaker, Collection, and some other stuff

[Alexandre Oliveira]

I've been looking at how the querymaker stuff is going, and if I
understand it well, it looks very nice, except from one point:  the
doSomethingWithXYZ methods, where XYZ are Artist, Album, Genre, etc.
By doing things this way we'll be obliged to always handle each meta
value class diferently. Ideally, I should be able to add a MetaPtr to
a QueryBuilder as a Match, and it should be added correctly no matter
it's a Artist, a Album, or another metadata. The same for any other
method.

It's easy to make things work this way, paying the price of coupling
the meta classes to the query's.
All methods in QueryMaker and friends would always take a MetaPtr, and
call a virtual method on it that could be reimplemented in each class.
These methods should them build the "query" by calling methods similar
to the ones we have in the old query builder.  We'll need to have
something like that anyway, as we'll need some quite complicated
custom queries. Of course, we shouldn't make them work directly on
table/field names, as it won't be only for sql this time.
This way it would work without any problems no matter your using it
with MetaPtr or the other classes.
Inverting the logic like this brings another advantage: if in the
future we decide to add other Meta classes, it'll be easier, as most
of the changes will be in the new classes themselves, instead of
having to add lots of methods to different classes.
By the other hand, it might make the number of methods on the Meta
classes  explode to quite a big number, but I don't think it'll
happen.