db_query_bound() $arr_parms defaults to false instead of null

This is is to align the parameter's type to what ADOdb expects - in
v5.19 the Execute() method was modified to perform a strict type check
on the parameter, causing database errors when it receives 'null' if
there are no parameters to the query being executed.

Fixes #13713
Fix indentation
Logging API: fix array to string conversion notice

log_event() used $p_msg to print the message, instead of the sanitized
$s_msg variable, so when logging DB events which are submitted as an
array with execution time, the notice gets triggered.

Regression introduced by 2d0df25ec0fc7d9a0d97c8e5e102b617e5ff96d9
oci8 no longer needs special fetch mode with ADOdb 5.19

Fixes #15426
Fix ORA-01400 when adding new version

Regression introduced by commit a80f447687722b52160d00c96c21a5be5f4329e1
which removed the call to db_prepare_bool().

Fixes #17333
Consistently use db_prepare_bool() for boolean columns

In Version API, the released column was treated as an integer, despite
the fact that it's defined as 'L' in the schema. This can cause problems
with PostgreSQL.
Update constants for consistency underlying db column type

We define constants VERSION_FUTURE = 0 and VERSION_RELEASED = 1
for use with project_version.released column. However, it is defined as
type 'L' which maps to boolean in some DB types.

To prevent errors caused by mismatched data types, the constants are now
using true/false. If we ever need to store more values, the column's
type should be changed to integer in the schema.