(cherry picked from commit e4e8ebd9e0037812436a1588809deb23e0f3751a)

https://dev.yorhel.nl/ncdu/bug/112

'char' may be unsigned on some architectures, which will cause the
"overflow check" on decrement to fail.

This would at most result in a confusing UI issue where no confirmation
option appears to be selected.

I've decided not to use ls-like file name coloring for now, instead just
coloring the difference between a (regular) file and a dir.

Still looking for a good color scheme for light backgrounds.

TODO:
- Add (ls-like) colors to the actual file names
  -> Implement full $LS_COLORS handling or something simple and custom?
- Test on a white/black terminal, and provide an alternate color scheme
  if necessary.
- Make colors opt-in?

Turns out that being able to open an empty directory actually has its
uses:
- If you delete the last file in a directory, you now won't be directed
  to the parent directory anymore. This allows keeping 'd' pressed
  without worrying that you'll delete stuff outside of the current dir.
  (This is the primary motivation for doing this)
- You can now scan and later refresh an empty directory, as suggested by
  #2 in http://dev.yorhel.nl/ncdu/bug/15

Damn, it's 2012 already.

This should also allow compilers to generate better code.

Here is the new multi-page listing functionality I promised in
5db9c2ae.

It may look very easy, but getting this to work right wasn't,
unfortunately.

Rather than the ugly hack in delete.c.

The directory sizes are now incorrect as hard links will be counted
twice again (as if there wasn't any detection in the first place), but
this will get fixed by adding a shared size field.

This method of keeping track of hard links is a lot faster and allows
adding an interface which lists the found links.

Fixes bug #2789781.

Setting FF_BSEL after calling browse_init() causes two items to be
selected, as browse_init() makes sure something will be selected,
while calc_process() assumes nothing is, because the previously
selected item had just been deleted.

Hard link detection is now done in a separate pass on the in-memory tree,
and duplicates can be 'removed' and 're-added' on the fly. When making any
changes in the tree, all hard links are re-added before the operation and
removed again afterwards.

While this guarantees that all hard link information is correct, it does
have a few drawbacks. I can currently think of two:

 1. It's not the most efficient way to do it, and may be quite slow on
    large trees. Will have to do some benchmarks later to see whether
    it is anything to be concerned about.

 2. The first encountered item is considered as 'counted' and all items
    encountered after that are considered as 'duplicate'. Because the
    order in which we traverse the tree doesn't always have to be the
    same, the items that will be considered as 'duplicate' can vary with
    each deletion or re-calculation. This might cause confusion for
    people who aren't aware of how hard links work.

So we're actually back to having one header file for everything,
except it's now maintainable.

That's what you get when you change the way a function works...

ncdu already does seem to handle longer paths now, though there are
still a few places where the code still relies on PATH_MAX. Will fix
those later.

suseconds_t isn't always defined on some systems, but all possible
values are guaranteed to fit into a long, so use that.

...that was for debugging, which isn't necessary anymore.

This makes deleting multiple files a -lot- easier...

git-svn-id: svn://blicky.net/ncdu/trunk@48 ce56bc8d-f834-0410-b703-f827bd498a76

git-svn-id: svn://blicky.net/ncdu/trunk@36 ce56bc8d-f834-0410-b703-f827bd498a76

git-svn-id: svn://blicky.net/ncdu/trunk@34 ce56bc8d-f834-0410-b703-f827bd498a76