I plan to add more display options, but ran out of keys to bind.
Probably going for a quick-select menu thingy so that we can keep the
old key bindings for people accustomed to it.

The graph width algorithm is slightly different, but I think this one's
a minor improvement.

The exported file format is fully compatible with ncdu 1.x, but has a
few minor differences. I've backported these changes in
ca51d4ed

(+ 2 minor crash fixes due to out-of-bounds cursor_idx)

Now we're getting somewhere. This works surprisingly well, too. Existing
ncdu behavior is to remember which entry was previously selected but not
which entry was displayed at the top, so the view would be slightly
different when switching directories. This new approach remembers both
the entry and the offset.

I initially wanted to keep a directory's block count and size as a
separate field so that exporting an in-memory tree to a JSON dump would
be easier to do, but that doesn't seem like a common operation to
optimize for. We'll probably need the algorithms to subtract sub-items
from directory counts anyway, so such an export can still be
implemented, albeit slower.

libc locale-dependent APIs are pure madness, but I can't avoid them as
long as I use ncurses. libtickit seems like a much saner alternative (at
first glance), but no popular application seems to use it. :(

Eaiser to implement now that we're linking against libc.

But exclude pattern matching is extremely slow, so that should really be
rewritten with a custom fnmatch implementation. It's exactly as slow as
in ncdu 1.x as well, I'm surprised nobody's complained about it yet.
And while I'm at it, supporting .gitignore-style patterns would be
pretty neat, too.

I tried playing with zbox (pure Zig termbox-like lib) for a bit, but I
don't think I want to have to deal with the terminal support issues that
will inevitably come with it. I already stumbled upon one myself: it
doesn't properly put the terminal in a sensible state after cleanup in
tmux. As much as I dislike ncurses, it /is/ ubiquitous and tends to kind
of work.

Supporting kernfs checking is going to be a bit more annoying.
And so is exclude patterns. Ugh.

The new data model is supposed to solve a few problems with ncdu 1.x's
'struct dir':
- Reduce memory overhead,
- Fix extremely slow counting of hard links in some scenarios
  (issue #121)
- Add support for counting 'shared' data with other directories
  (issue #36)

Quick memory usage comparison of my root directory with ~3.5 million
files (normal / extended mode):

  ncdu 1.15.1:     379M / 451M
  new (unaligned): 145M / 178M
  new (aligned):   155M / 200M

There's still a /lot/ of to-do's left before this is usable, however,
and there's a bunch of issues I haven't really decided on yet, such as
which TUI library to use.

Backporting this data model to the C version of ncdu is also possible,
but somewhat painful. Let's first see how far I get with Zig.

Fixes #171

Use 'max(10, column_size / 7)' instead of a fixed size of 10

What a mess.

https://code.blicky.net/yorhel/ncdu/issues/153#issuecomment-764

Avoid undeclared identifiers when compiling with older kernel headers.

So we get around the PATH_MAX limitation. Also a tiny bit more
efficient, I hope.

Silly one-character typo that causes directory apparent sizes to be very
off in some scenarios.

Reported & patched by Andrew Neitsch.

Fixes #150

(cherry picked from commit a076ac714aa6fb24e0e9eb227372df84a4b6000b)

(cherry picked from commit ef7b4e5c28739c26b3a120296f9dc2ddaf2d4375)

(cherry picked from commit 9f28920a64c155957b83324cd3a3cf0fda6020c9)

(cherry picked from commit ad5b7fce74a3b7b0ed726620c81ea552c643cdad)

(cherry picked from commit 2faefc3b2432409f3ccca0b6ab53a228d5b9b00d)

(cherry picked from commit 32b77d0064d3e5f52e9204ddeffc29bb21a67753)

(cherry picked from commit ce7036d249b6f05633c343ab95d88552aab85402)

(cherry picked from commit 9801f46ece0ca2525f02d71464efc42296dddcb5)