Instead of growing the buffer for the tokens (and reallocating),
do one pre-run over the string and count the delimiters. This
way we know how much space we need and we don't need to
reallocate.

Interestingly, this is notably slower than the previous implementation,
because previously if would not bother determining the right number of
tokens but just over-allocate with a reasonable guess of 8 and grow the
buffer exponentially. Still, I like this better because while it may
be slower in common scenarios, it allocates the exact number of buffer
space.

Previously, nm_utils_strsplit_set_full() would always remove empty
tokens. Add a flag NM_UTILS_STRSPLIT_SET_FLAGS_PRESERVE_EMPTY to avoid
that.

This makes nm_utils_strsplit_set_full() return the same result as
g_strsplit_set() and a direct replacement for it -- except for "",
where we return %NULL.

Drop the next_char() and is_delimiter() macros. They are difficult to
understand, because they both have a state-variable (escaped).
Instead, the state of whether we handle an escape or not, shall only
depend on the current line of code.

The caller should make a conscious decision which delimiters to use.
Unfortunately, there is a variety of different demiters in use. This
should be unitfied and the callers should use one of a few specific
set of delimiters.

This could be unified by (re)using a define as delimiters, like

   strv = nm_utils_strsplit_set_full (value, MULTILIST_WITH_ESCAPE_CHARS, NM_UTILS_STRSPLIT_SET_FLAGS_ALLOW_ESCAPING);

where MULTILIST_WITH_ESCAPE_CHARS has a particular meaning that should
be reused for similar uses.

However, leaving the delimiter at NULL is not good because it's unclear who
wants that default behavior (and what the default should be). Don't allow that.

There are almost no callers that relied on this default anyway.

It will be useful to extend nm_utils_strsplit_set() with various
flavors and subtly different behaviors. Add a flags argument to
support these.

Traditionally, the MTU in "datagram" transport mode was restricted to
2044. That is no longer the case, relax that.

In fact, choose a very large maximum and don't differenciate between
"connected" mode (they now both use now 65520). This is only the
limitation of the connection profile. Whether setting such large MTUs
actually works must be determined when activating the profile.

Initscripts "ifup-ib" from rdma-core package originally had a limit of 2044.
This was raised to 4092 in rh#1186498. It is suggested to raise it further
in bug rh#1647541.

In general, kernel often does not allow setting large MTUs. And even if it
allows it, it may not work because it also requires the entire network to
be configured accordingly. But that means, it is generally not helpful to
limit the MTU in the connection profile too strictly. Just allow large
MTUs, we need to see at activation time whether the configuration works.

Note also that all other setting types don't validate the range for MTU at
all.

Related: https://bugzilla.redhat.com/show_bug.cgi?id=1186498
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1593334
         (rdma-core: raise limit from 2044 to 4092 in ifup-ib)

Related: https://bugzilla.redhat.com/show_bug.cgi?id=1647541
         (rdma-core: raise limit beyond 4092 in ifup-ib)

Related: https://bugzilla.redhat.com/show_bug.cgi?id=1532638#c4
         (rdma-core: MTU related discussion)

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1534869
       (NetworkManager bug about this topic, but with lots of unrelated
        discussion. See in particular #c16)

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1653494

Previously, this would re-implement what nm_strstrip_avoid_copy()
was doing.

Use nm_strstrip_avoid_copy_a() instead, which avoids the code
duplication and the heap allocation in common cases.

The main difference between "shared/nm-utils/nm-macros-internal.h" and
"shared/nm-utils/nm-shared-utils.h" is that the former is header-only
while the latter has a source file as well.

Apart from that, both headers are included everywhere.

The next commit will add nm_strstrip_avoid_copy_a() to
"nm-macros-internal.h" header, which will use nm_strndup_a().
Hence, also nm_strndup_a() should be in "nm-macros-internal.h".