This code was git cherry-picked from master, which uses C++11.

This lets people actually change the default field formatting again,
fixing bug #763348 (m.rick.mac)

This seems to have been broken since 2013-10:
https://git.gnome.org/browse/glom/commit/glom/mode_design/fields/box_db_table_definition.cc?id=2bb23a44

This seems to actually work. I don't think it worked for a while
after something changed about how GNOME does help files or IDs.

This fixes bug #763250 (m.rick.mac)

To avoid losing precision when representing a GdaNumeric value as a string.

And check this in test_field_file_format(), though a direct test too would
be better.

This should fix bug #763229 (m.rick.mac)

Like generated po/Makefile.in.in file does, to decide where to
instal the translation files.
Instead of guessing it based on the prefix, causing us not to show
the translations when staring in appropriate locale.
Bug #761372 (m.rick.mac)
And this fixes the 3 test cases that have been failing for me for
a while.

This must have been wrong for quite a long time, since GTK+ changed
its expand system.

Bug #762108 (m.rick.mac)

Because recent versions of libevince-view have an assert that crashes
the application:
https://bugzilla.gnome.org/show_bug.cgi?id=761396#c12

Why didn't the compiler catch this?

g++ seems to want this, at least with C++14, even though our
default switch case should be enough.

Otherwise, we still get the dropped table name when asking libgda
for a list of tables. This caused Glom to complain that a
previously-deleted table name already existed when the user tried to
recreate it.
Bug #754645 (m.rick.mac)

So we always get the same result regardless of the current locale,
because the "data" shouldn't really be locale-specific.
This has disadvantages for collation but we also want the database
to be fairly portable across environments.

This might help this bug:
https://bugzilla.gnome.org/show_bug.cgi?id=761372

Because this can fail in the real world and it would be nice to know
as soon as possible:
https://bugzilla.gnome.org/show_bug.cgi?id=761373

Instead of just assuming that all top-level groups are standard
groups. They could be derived groups, such as notebooks.

Bug #759511

And portals too. By not just assuming that the top-level groups
are normal groups. They can be derived groups, such as notebooks.

Bug #759511

Via the CONNECT_TIMEOUT paramater for libgda's cnc_string,
as listed by this command-line command:
  gda-sql-5.0 -L PostgreSQL

Found by cppcheck.