[BUG] splitIndex with skipHash corrupts index and crashes status

[Andy Koppe <andy.koppe@gmail.com>]

With both core.splitIndex and index.skipHash enabled (the latter e.g.
via feature.manyFiles), index entries are silently lost or corrupted
whenever the shared index is written.

  $ git init -q r && cd r
  $ git config core.splitIndex true
  $ touch foo bar && git add . && git commit -qm init
  $ git config index.skipHash true
  $ git update-index --split-index
  $ git ls-files
  ./
  ./
  $ git status --short
  BUG: wt-status.c:585: multiple renames on the same target? how?
  Aborted (core dumped)

Without the explicit --split-index, this happens once the shared index
is rewritten because enough entries have changed.

In a new repository, the first git add writes a shared index, and the
added entry is lost straight away:

  $ git init -q r && cd r
  $ git config core.splitIndex true
  $ git config index.skipHash true
  $ touch foo && git add foo
  $ git status --short
  ?? foo
  $ ls .git | grep index
  index
  sharedindex.0000000000000000000000000000000000000000

Note the unexpected null OID.

Seen with v2.56.0 on x86_64 Linux.