... initial empty strings.

The tests pass, which is encouraging.

… docs

These are non-critical, so their behavior is ok to change.
Dropping empty items is not needed and usually not expected.

…attr

The empty attribute name should not be dropped from attribute paths.
Rendering attribute paths with concatStringsSep is lossy and wrong,
but this is just a first improvement while dealing with the
dropEmptyInitThenConcatStringsSep problem.

Bug not reported in 6 years, but here you go.

Also it is safe to switch to normal concatStringsSep behavior
because tokenizeString does not produce empty items.

The sigs field is produced by tokenizeStrings, which does not return
empty strings.

…ot empty

…ty not feasible

I don't think it's completely impossible, but I can't construct
one easily as derivationStrict seems to (re)tokenize the outputs
attribute, dropping the empty output.

It's not a scenario we have to account for here.

… not empty

…not be empty

(System) features are unlikely to be empty strings, but when they
come in through structuredAttrs, they probably can.
I don't think this means we should drop them, but most likely they
will be dropped after this because next time they'll be parsed with
tokenizeString.

TODO: We should forbid empty features.

…atures do not render as empty strings

…rgs are never empty

…hould not be empty

…ributes with empty names

Empty attributes are probably not well supported, but the least we
could do is leave a hint.
Attribute path rendering and parsing should be done according to
Nix expression syntax in my opinion.

…e not empty

…"" "" "" build

Garbage in, error out. Experimental CLI. Zero derivations given.

…rsion is not empty

The law has nothing to do with this, although I do feel like a
badass when I mess with the config.
I'm a conf artist.

…enizeString are not empty

…as already harmed

Considering that `value` was probably parsed with tokenizeString
prior, it's unlikely to contain empty strings, and we have no
reason to remove them either.

It's still wrong, but one step closer to correct.
Not that anyone should use "" or "." in their PATH, but that is not
for us to intervene.

It's usually harmless, if it occurs at all.

When the separator is empty, no difference is observable.

Note that concatStringsSep has centralized definitions. This adds the
required definitions. Alternatively, `strings-inline.hh` could be
included at call sites.

... at call sites that are may be in the hot path.

I do not know how clever the compiler gets at these sites.
My primary concern is to not regress performance and I am confident
that this achieves it the easy way.