Thomas Haller authored May 01, 2019 and Lubomir Rintel committed May 21, 2019

- g_ascii_strtoll() accepts leading spaces, but it leaves
  the end pointer at the first space after the digit. That means,
  we accepted "1: 0" but not "1 :0". We should either consistently
  accept spaces around the digits/colon or reject it.

- g_ascii_strtoll() accepts "\v" as a space (just like `man 3 isspace`
  comments that "\v" is a space in C and POSIX locale.
  For some reasons (unknown to me) g_ascii_isspace() does not treat
  "\v" as space. And neither does NM_ASCII_SPACES and
  nm_str_skip_leading_spaces().
  We should be consistent about what we consider spaces and what not.
  It's already odd to accept '\n' as spaces here, but well, lets do
  it for the sake of consistency (so that it matches with our
  understanding of ASCII spaces, albeit not POSIX's).

- don't use bogus error domains in "g_set_error (error, 1, 0, ..."
  That is a bug and we have NM_UTILS_ERROR exactly for error instances
  with unspecified domain and code.

- as before, accept a trailing ":" with omitted minor number.

- reject all unexpected characters. strtoll() accepts '+' / '-'
  and a "0x" prefix of the numbers (and leading POSIX spaces). Be
  strict here and only accepts NM_ASCII_SPACES, ':', and hexdigits.
  In particular, don't accept the "0x" prefix.

This parsing would be significantly simpler to implement, if we could
just strdup() the string, split the string at the colon delimiter and
use _nm_utils_ascii_str_to_int64() which gets leading/trailing spaces
right. But let's save the "overhead" of an additional alloc.

(cherry picked from commit cc9f0716)