memory leak in oltp prepare step

Originally reported by Christian Ehrhardt at SourceForge:

"
The prepare step of oltp uses db_query which implicitly allocates a result set,
but doesn't care about it.
Due to that the result set is never freed which causes the oltp test prepare
step consume almost as much process memory as the database size of the created
DB will be.

Eventually the symptom where crashes due to the oom-killer as soon as sysbench
was requested to create databases bigger than ram+swap.

The leak was found using valgrind:
Before Fix:
9,992,400 bytes in 49,962 blocks are definitely lost in loss record 40 of 40
at 0x40079E6: malloc (vg_replace_malloc.c:236)
by 0x41CCD34699: PQmakeEmptyPGresult (in /usr/lib64/libpq.so.5.2)
by 0x41CCD3E093: ??? (in /usr/lib64/libpq.so.5.2)
by 0x41CCD35273: PQgetResult (in /usr/lib64/libpq.so.5.2)
by 0x41CCD35543: ??? (in /usr/lib64/libpq.so.5.2)
by 0x8000EB33: pgsql_drv_query (drv_pgsql.c:557)
by 0x8000661D: db_query (db_driver.c:404)
by 0x8000B29D: oltp_cmd_prepare (sb_oltp.c:464)
by 0x4ED756A893: (below main) (in /lib64/libc-2.12.so)

LEAK SUMMARY:
definitely lost: 9,993,885 bytes in 49,965 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 13,176 bytes in 281 blocks
still reachable: 1,548 bytes in 15 blocks
suppressed: 0 bytes in 0 blocks

After Fix:
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 6,976 bytes in 250 blocks
still reachable: 148 bytes in 8 blocks
suppressed: 0 bytes in 0 blocks

To fix that this patch introduces a wrapper called db_query_nors (nors = no
record set). That wrapper calls db_query for the work, but frees up the
retrned record set.
Due to that all the checks based on the returned pointer could be simplified
as well as they no more need the "== NULL" portion.

While fixing that I also removed the not needed == NULL checks in the call
to the db_query function and rewrite to equal error messages so users can
differentiate them.
Feel free to put all that in an extra commit if you want to split that.

I created a fix which is now in use for about two months and works fine so far.
It is attached to this bug, so please review and apply if you consider it useful.
"