Or force the use of a library with --with-ncurses or --with-ncursesw.
Implementation based on/stolen from the configure.ac in ncmpc.

These ideas may not be very easy to implement, and may not be worth
the performance penalty they might introduce. But that's something that
still needs to be investigated.

Fixes bug #2831412 (debian #539553)

...instead of displaying an empty and unusable browser.

When interrupinting the calculation process by pressing 'q' while
it's looping through a directory, or when a directory could be openend
but not chdir()'ed into, closedir() wasn't called.

This fixes a tiny memory leak as well, as the return value of opendir()
wasn't passed to a closedir() after use.

Fixes bug #2789781.

There shouldn't be a need for such a state when there's a central
place where the program execution keeps returning to.

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.

I happen to make these kinds of mistakes a lot, for some strange
reason. Maybe I should just get more sleep...

Reproducable with the following steps:
- Make sure the first item in the list is a directory starting with a dot
- Make sure the next item is a normal directory
- Select first item
- Press 'h' to hide it, next item will properly be selected
- Open selected directory (right arrow), and see how the first (hidden)
  directory was opened.

It's amazing how I've even found this bug, considering that really is the
only way to reproduce it...

It's a floating point division, so won't really cause any real problems
on most systems. Still, a percentage of 'nan' isn't really useful.

Which would happen if there's only one file is in a directory

Removed some obsolete macros and added a few more headers and function
checks.

I really, really, wasn't think when writing commit
91b131a0

Bug introduced in ece21a66
It's amazing how many mistakes one person can make in a few hours.

Bug introduced in 796d043c
Apparently I was still sleeping or something...

And it wasn't even used for a path, but for a row on the screen...

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