Introduce Query builder

[yhabteab]

refs #6

[lippserd]

I would find it clearer if the API did not require the query builder to be created again and again. It would also be more flexible if the different statement types were separate structs.

[julianbrost]

If we're starting to discuss the overall API design this PR won't do it to get Icinga/icinga-notifications#114 merged any time soon. So either we merge this as an experimental API (i.e. might fundamentally change) or we need another PR that simply exposes a BuildColumns() function again so that this can be used by Icinga/icinga-notifications#114 in the meantime.

[lippserd]

If we're starting to discuss the overall API design this PR won't do it to get Icinga/icinga-notifications#114 merged any time soon. So either we merge this as an experimental API (i.e. might fundamentally change) or we need another PR that simply exposes a BuildColumns() function again so that this can be used by Icinga/icinga-notifications#114 in the meantime.

I see. Then let’s just merge it.

[julianbrost]

or we need another PR that simply exposes a BuildColumns() function again so that this can be used by Icinga/icinga-notifications#114 in the meantime

I've asked for this to be done nonetheless as I find the current interface this PR adds more confusing than it needs to be in regards to what it accepts in any parameters. And even if it's kept that way, the current implementation has room for improvement by reducing the amount of use of the reflect package. All in all, more than what should be necessary to finally get Icinga Notifications away from importing Icinga DB as a package.