UseDeclareFetch bugs, found & fixed

Hi all,

If you run the pgsql-odbc regression suite with UseDeclareFetch=1, you
get two failures:

1. notice

> *** psqlodbc/test/expected/notice.out    2014-03-24 08:45:07.567976184 +0200
> --- psqlodbc/test/results/notice.out    2014-04-11 15:00:01.250084814 +0300
> ***************
> *** 1,7 ****
>   \! ./src/notice-test
>   connected
> - got SUCCESS_WITH_INFO
> - 00000=NOTICE: test notice: foo
> - got SUCCESS_WITH_INFO
> - 00000=
>   disconnecting
> --- 1,3 ----

In a nutshell, with UseDeclareFetch=1, NOTICE messages are lost. The
server sends them to the client with the response to the DECLARE CURSOR
statement, but the driver throws away the response to DECLARE CURSOR. It
waits for the response to the FETCH statement, and returns that instead.
To fix, before throwing away the response, copy any NOTICE messages from
the Qresult for the DECLARE CURSOR forward to the next Qresult.

2. dataatexecution

> *** /home/heikki/git-sandbox-pgsql/psqlodbc/test/expected/dataatexecution.out    2014-03-24 08:45:07.567976184 +0200
> --- /home/heikki/git-sandbox-pgsql/psqlodbc/test/results/dataatexecution.out    2014-04-11 15:00:05.934040285 +0300
> ***************
> *** 3,12 ****
>   Result set:
>   2
>   3
> ! Parameter    Status
> ! Fetching result sets for array bound (2 results expected)
> ! 1: Result set:
> ! 4
> ! 2: Result set:
> ! 5
> ! disconnecting
> --- 3,8 ----
>   Result set:
>   2
>   3
> ! SQLParamData failed
> ! 42P03=ERROR: cursor "SQL_CUR0xe20060" already exists;
> ! Error while executing the query

Even though it's the dataatexecution regression test that fails, this
isn't related to data-at-execution, but array-binding of parameters.
With array-bound parameters, the driver will execute the same statement
multiple times, once for each set of parameters. If the statement is a
SELECT-query, it will try to execute the "DECLARE CURSOR" many times,
without closing the cursor inbetween, which fails.

To fix, I just disabled using cursors with array-bound parameters. I'm
not sure if there would be a better fix - like close the cursor between
the calls - but this is good enough for me.

I pushed a fix for those.

- Heikki