Make new sd-path configuration search functionality generic (#39684)

Reverts systemd/systemd#38680

After taking a closer look I'm not convinced by the approach, see below.

First of all, all other SD_PATH_SEARCH_* are either somewhat generic,
i.e. encode the common prefix for configurations, binaries, etc., or are
subdirectories under systemd/ hence in our own "domain". The
tmpfiles/sysctl/binfmt we don't prefix with "systemd" precisely because
the concept is generic and there're actually other impls of them. A
specific SD_PATH_SEARCH_SYSCTL doesn't fit into our existing scheme.
Instead something along the lines of "SEARCH_SYSTEM_CONFIGURATION" shall
be introduced, and consumers will just suffix
sysctl.d/tmpfiles.d/binfmt.d for the final result.

And secondly, I don't grok why systemd-sysctl now unnecessarily calls
into sd-path to obtain the fixed search path. None of our other tools do
that.

-----------

An alternate approach, SD_PATH_SYSTEM_SEARCH_CONFIGURATION, which does
exactly above, will be introduced instead. It provides a universal
interface for querying any system config with our idiomatic
/etc/:/run/:/usr/local/lib/:/usr/lib/ hierarchy.

src/libsystemd/sd-path/sd-path.c

@@ -524,6 +524,9 @@ static int get_search(uint64_t type, char ***ret) {
 
         switch (type) {
 
+        case SD_PATH_SYSTEM_SEARCH_CONFIGURATION:
+                return strv_from_nulstr(ret, CONF_PATHS_NULSTR(""));
+
         case SD_PATH_SEARCH_BINARIES:
                 return search_from_environment(ret,
                                                NULL,
@@ -683,11 +686,7 @@ static int get_search(uint64_t type, char ***ret) {
 
                 *ret = TAKE_PTR(l);
                 return 0;
-        }
-
-        case SD_PATH_SEARCH_SYSCTL:
-                return strv_from_nulstr(ret, CONF_PATHS_NULSTR("sysctl.d"));
-        }
+        }}
 
         return -EOPNOTSUPP;
 }