- previously, writer would use nm_keyfile_plugin_kf_set_integer() for
  G_TYPE_UINT types.
  That means, values larger than G_MAXINT would be stored as negative
  values. On the other hand, the reader would always reject negative
  values.
  Fix that, by parsing the integer ourself.
  Note that we still reject the old (negative) values and there is no
  compatibility for accepting such values. They were not accepted by
  reader in the past and so they are still rejected.
  This affects for example ethernet.mtu setting (arguably, the MTU
  is usually set to small values where the issue was not apparent).
  This is also covered by a test.

- no longer use nm_keyfile_plugin_kf_set_integer().
  nm_keyfile_plugin_kf_set_integer() calls g_key_file_get_integer(), which
  uses g_key_file_parse_integer_as_value(). That one has the odd
  behavior of accepting "<number><whitespace><bogus>" as valid. Note how that
  differs from g_key_file_parse_value_as_double() which rejects trailing data.
  Implement the parsing ourself. There are some changes here:

  - g_key_file_parse_value_as_integer() uses strtol() with base 10.
    We no longer require a certain the base, so '0x' hex values are allowed
    now as well.

  - bogus suffixes are now rejected but were accepted by g_key_file_parse_value_as_integer().
    We however still accept leading and trailing whitespace, as before.

- use nm_g_object_set_property*(). g_object_set() asserts that the value
  is in range. We cannot pass invalid values without checking that they
  are valid.

- emit warnings when values cannot be parsed. Previously they would
  have been silently ignored or fail an assertion during g_object_set().

- don't use "helpers" like nm_keyfile_plugin_kf_set_uint64(). These
  merely call GKeyFile's setters (taking care of aliases). The setters
  of GKeyFile don't do anything miraculously, they merely call
  g_key_file_set_value() with the string that one would expect.
  Convert the numbers/boolean ourselfs. For one, we don't require
  a heap allocation to convert a number to string. Also, there is
  no point in leaving this GKeyFile API, because even if GKeyFile
  day would change, we still must continue to support the present
  format, as that is what users have on disk. So, even if a new
  way would be implemented by GKeyFile, the current way must forever
  be accepted too. Hence, we don't need this abstraction.