Add brace initialisers to coding standard

[hannes-steffenhagen-diffblue]

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• White-space or formatting changes outside the feature-related changed lines are in commits of their own.

Major benefit:

• C++ standard requires a diagnostic on narrow conversions in brace initialisers, e.g.

#include <iostream>

struct X {
  char x; 
  X(char x) : x(x) {}
};

struct Y {
  float x;
  Y(float x) : x(x) {}
};

int main()
{
  int val = 10;
  // may or may not warn (does not by default in g++)
  auto const a = X(val);
  // diagnostic required by C++ standard!
  auto const b = X{val};

  double dval = 3.0;
  // again, no warning with g++
  auto const c = Y(dval);
  // diagnostic required
  auto const d = Y{dval};
}

Minor benefits:

• Can visually distinguish constructor from function calls
• Can use slightly more consistent syntax type_name variable_name{}; instead of type_name variable_name; (parentheses version doesn't work because it's indistinguishable from a function declaration)

[tautschnig]

I'm largely a "don't care" on this one - I find it visually displeasing, but that's probably just because I'm not yet used to it. So I'll have someone else approve. (The major benefit mentioned in the PR description I'd just comment on with "use explicit.")

[tautschnig]

Suggested change

	parentheses for constructor calls
	parentheses for constructor calls.

[allredj]

🚫
This PR failed Diffblue compatibility checks (cbmc commit: 38b1b98).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/94044400
Status will be re-evaluated on next push.
Please contact @peterschrammel, @thk123, or @allredj for support.

Common spurious failures:

• the cbmc commit has disappeared in the mean time (e.g. in a force-push)
• the author is not in the list of contributors (e.g. first-time contributors).

The incompatibility may have been introduced by an earlier PR. In that case merging this
PR should be avoided unless it fixes the current incompatibility.

[hanst99]

This is also in CPPCoreGuidelines, which we obviously don't follow atm but I feel like if we don't have a particular preference either way going with those is a good start. They also have more detailed reasoning for their recommendations most of the time.

[NlightNFotis]

I'm all for it, especially for the benefit of not allowing implicit narrowing conversions.