Fix int and long mismatch for vector in ODBC

This is attempt to investigate and solve problems with failing ODBC tests after Travis CI switched to Linux VMs from 32-bit to  64-bit.
Apparently, there is mismatch of C++ types vector<int> and vector<long> int with use() and into(). ODBC backend relies on C++ sizeof and casting, so mixing 4-byte int with 8-byte long on Linxu 64-bit is asking for troubles.

This commit may be incomplete and serves purpose of illustration of the problem, needs to be reviewed and improved if needed. As the common-tests.h have been changed, it is necessary to verify those changes against other backends as well.
(Problems of this sort prove that sorting out strong requirements regarding C++ integer type support is a must.)
Notify soci-devel about Travis CI builds failure
Promote README important content

[ci skip]
Add debian-oracle10g-install.sh script

The script installs Oracle XE 10g on OpenVZ VM in non-interactive mode. It is used to setup VM for SOCI testing.
[ci skip]
Merge pull request #103 from mloskot/hotfix/odbc-vector-int

Fix int and long mismatch for vector in ODBC
Remove redundant URL
Specify gitflow branches to build
Correct release/ branch name
Fix harmless signed/unsigned comparison warnings in Firebird code.

At least MSVC warns about comparing unsigned std::string::size() result with a
signed value, fix the warning by simply converting the former to signed int.
Fix regression with statement re-execution when using Firebird backend.

Since the introduction of endOfRowSet_ flag in 4c3cb629, executing the same
statement again stopped working as the flag was never reset after fetching all
the results of the first execution.

Fix this by resetting it in firebird_statement_backend::execute().

Also add a test verifying that this does indeed work.
Use type big enough to store unsigned long in Firebird tests.

Using decimal(9,0) for the "ul" field of the test database translates into
using SQL_LONG type at Firebird API level which, in turn, translates into
"int" at C++ level. And casting int values to unsigned long doesn't work
correctly on LP64 architectures where the former is 32 bits while the latter
is 64 bits.

This resulted in test failures when reading values > INT_MAX from the
database, as could be seen in the unit tests before 4c3cb629 masked it by
casting to unsigned int first. This, however, was inconsistent with the other
data types and broke reading of doubles from the database and will be undone
soon.

So use another fix for the unit tests: just create the field using "bigint"
type (alias for decimal(18,0)) which translates into SQL_INT64 and doesn't
truncate the value when casting it. This is also consistent with the other
backends that mostly use decimal(20,0) for this field.
Fix reading negative doubles from the database with Firebird backend.

Mantissa of type SQL_LONG must be converted to "int", not "unsigned", when
reading from the database.

This corrects the changes of 4c3cb629 which did use int in other places where
SQL_LONG is handled but not here to compensate for a different bug with
handling of unsigned long which is fixed differently by the previous commit.

Also add unit a (Firebird-specific for now but it should be made common) test
for reading negative doubles.
Use standard "||" instead of "or" keyword in Firebird backend code.

MSVC doesn't support the use keywords for logical operators without including
<iso646.h> first. Instead of doing this and possibly running into more
problems on other systems, just use the standard C operators.
Fixes a crash and allows creating complex function

First fix around line 95 allows passing any query containing an assignment operator (:=) this way we can create complex functions within soci.
Second fix around line 172 avoids causing a second exception on the destructor when you have a 'statementName_' but actually PQPrepare() failed and threw a first exception.
Test functions with ':=' and causes a crash case

Tests if soci can create psql functions with assignments (:=).
Tests the situation where preparing an invalid query caused a crash with certain combinations of client/server versions.
Add PPC64 to tested platforms.

Based on info provided by Brian in #106
Remove linking against Oracle OCIEI lib.

This should make a minimal approach to solve #89.
According to discussion on OTN, there is no reason to link against libociei directly as the exposed client interfaces are in the libclntsh.dylib file and we should only be linking against the client library. See details at https://forums.oracle.com/forums/thread.jspa?threadID=2506565

If possible, I'd prefer to keep FindOracle.cmake minimal as SOCI does not need fully-featured FindOracle.cmake from TOra. Also, TOra's module follows outdated idiom instead of canonical use of FindPackageHandleStandardArgs as explained in this thread http://www.cmake.org/pipermail/cmake/2010-March/035597.html
In future, it would be great to combine both modules and refactor according to current CMake guidelines.
Add ORACLE_HOME to ORACLE_LIB_DIR

This is non-intrusive patch required by MacPorts: http://trac.macports.org/browser/trunk/dports/databases/soci-devel/files/patch-src-cmake-modules-FindOracle.cmake.diff?rev=84842
Related to issues discussed in #89

[ci skip]
Restore previous list of ORACLE_OCI_NAMES

This is quick and dirty trick that seem to help to workaround the mysterious CMake failure (#89).
It needs to be tested if linking works.

[ci skip]
Generate list of chnages in 3.2.0