Support a new configuration option

  [.config]
  enable=<ENABLED>

for configuration snippets.

This new [.config] section is only relevant within the snippet itself
and it is not merged into the combined configuration.

Currently only the "enable" key is supported. If the "enable" key is
missing, it obviously defaults to being enabled. It allows snippets
to be skipped from loading. The main configuration "NetworkManager.conf"
cannot be skipped.

<ENABLED> can be a boolean value (false), to skip a configuration
snippet from loading.
It can also be a string to match against the NetworkManager version,
like "enable=nm-version-min:1.1,nm-version-min:1.0.6"

There are several motivations for this:

- the user can disable an entire configuration snippet by toggeling
  one entry.
  This generalizes  the functionality of the global-dns.enable
  setting, but in a way that applies to configuration on a per-file
  basis.

- for developing, we often switch between different versions of
  NetworkManager. Thus, we might want to use different configuration.
  E.g. before global-dns options, I want to use "dns=none" and manage
  resolv.conf myself. Now, I can use global-dns setting to do that.
  That can be achieved with something like the following (not exactly,
  it's an example only):

      [.config]
      enable=nm-version-min:1.1
      [main]
      dns=default
      [global-dns-domain-*]
      nameserver=127.0.0.1

  Arguably, this would be more awesome, if we would bump our micro devel
  version (1.1.0) more often while developing 1.2.0 (*hint*).

- in principle, packages could drop configuration snippets and enable
  them based on the NetworkManager version.

- with the "env:" spec, you can enable/disable snippets by configuring
  an environment variable. Again, useful for testing and developing.

It is wrong to blindly merge keys that have an 'option+' or 'option-'.
Merging options is only possibly when we understand what the option
means and how to merge it.

No longer handle every setting but only those that are explicitly known
to be string-lists (or device-specs).

We have a hack to extend GKeyFile to support specifying an 'option+'
key. Also add support for 'option-'.

Options that make use of these modifiers can only be string lists.
So do the concatenation not based on plain strings, but by treating
the values as string lists. Also, don't add duplicates.

We support the "NetworkManager.conf" sections '[connection]' and
'[connection.\+]' (with arbitrary suffix).

Fix the order of how we evaluate these section.

Note that the literal '[connection]' section is always evaluated lastly
after any other '[connection.\+]' section.

Within one file, we want to evaluate the sections in top-to-bottom
order. But accross multiple files, we want to order them
later-files-first. That gives a reasonable behavior if the user
looks at one file, and also if he wants to overwrite configuration
via configuration snippets like "conf.d/99-last.conf".

Note that if a later file extends/overwrites a section defined in an
earlier file, the section is still considered with lower priority
This is intentional, because the user ~extends~ a lower priority
section. If he wants to add a higher priority section, he should
choose a new suffix.

Fixes: dc0193ac023e30a9a3794e78c66f8c5266695a60

Some subdirectories of src/ encapsulate large chunks of functionality,
but src/config/, src/logging/, and src/posix-signals/ are really only
separated out because they used to be built into separate
sub-libraries that were needed either for test programs, or to prevent
circular dependencies. Since this is no longer relevant, simplify
things by moving their files back into the main source directory.