When "Untracked files" has not been expanded yet, then its children
slot is nil, for performance reasons.  For this section most callers
treat the returned value as a boolean, so just return t instead.

One caller, which did not treat the value as a boolean, has to be
adjusted.

Closes #5366.

Inserting rebase actions into the status buffer when --rebase-merges
is specified triggers two errors with the v4.3.3 release:

 1) a type error due to empty lines in the todo list

 2) an unbound slot error due to misalignment between the abbrevs list
    returned by 'git log --no-walk --format=%h <commit>...' and the
    input commits

The first was resolved a few commits back with 621e69eb
(magit-rebase-insert-merge-sequence: Skip over empty lines).

The second error is avoided by 4fc60fdb (magit-rebase--todo: Deal with
duplicated commits).  The new logic requests that the git-log call
also output the full hash so that abbrevs can be used as an alist
mapping a long hash to an abbreviated one.  But the output lines are
not actually split from the '%H %h' strings into alist entries, so the
magit-rev-abbrev fallback always fires, eliminating the v4.3.3 speedup
that came from the one-shot git-log call.

The known reason for having duplicate commits across rebase todo lines
is that, when constructing commits to pass to git-log, a faulty
always-nil condition prevents the commit from being extracted from the
-C/-c options of merge lines.  Once that condition is fixed, I haven't
found a case where two todo lines point to the same commit.

Revert the changes from 4fc60fdb and instead fix the merge condition,
adding an assertion on top so that someone will let us know if they
hit into a case where the resolved number of commits is fewer.

(Also, specify --no-walk=unsorted to ensure commits come back in the
order in which they were passed to git-log.)

Re: #5365

Closes #5365.