Split calc.c into separate components (dir_(mem|scan|common).c)

The architecture is explained in dir.h. The reasons for these changes is
two-fold:
- calc.c was too complex, it simply did too many things. 399ccdeb is a
  nice example of that: Should have been an easy fix, but it introduced
  a segfault (fixed in 0b49021a), and added a small memory leak.
- This architecture features a pluggable input/output system, which
  should make a file export/import feature relatively simple.

The current commit does not feature any user interface, so there's no
feedback yet when scanning a directory. I'll get to that in a bit.

I've also not tested the new scanning code very well yet, so I might
have introduced some bugs.
Re-added scanning UI and improved error handling
Fixed some compiler warnings and a (rather nonexistent) memory leak

This silences clang and gcc with -O2 -Wall -Wextra
Added -u option to change the scan UI

This allows scanning stuff without initializing ncurses. Not too useful
at this point since ncdu will switch to an ncurses environment when it's
done anyway, but this will become more useful when the export-to-file
feature has been implemented.
Use int64_t instead of off_t

*Should* be equivalent, but having a clearly standardised width is much
better.
Use int instead of long for struct dir->items

2 billion files should be enough for everyone. You probably won't have
enough memory to scan such a filesystem. int is a better choice than
long, as sizeof(int) is 4 on pretty much any system where ncdu runs.
Use uint64_t instead of ino_t

POSIX defines ino_t to be of an unsigned integer type, and searching
around the net didn't tell me of any definitions conflicting that. So
every ino_t can be represented in an uint64_t. (Assuming that is the
largest integer type in use for an inode number, but I'm sure that
assumption will hold for a while)

(dev_t, on the other hand, is a bit messier. Still figuring out what to
do with that.)
Use uint64_t instead of dev_t as well + added comment explaining this
Fixing some whitespace issues
Get rid of padding in dir struct + use offsetof() to calc needed size

There used to be four bytes of padding in the struct on systems with
32bit pointers. Moving the pointers down so that they are in between the
64bit and 32bit fields means that there'll never be any padding.

There may, however, be some extra padding at the end of the struct to
make the size a multiple of 8. Since we use the name field as a sort of
"flexible array member", we don't particularly care about that padding
and just want to allocate enough memory to hold the struct and the name
field. offsetof() allows us to do that without relying on compiler
support for flexible array members.
configure: Removed a few useless checks

There's no need to check -lncursesw twice, for example.
Added -o option to export dir structure to a JSON-encoded file

!WARNING! The export option is experimental, and the file format is not
final. I make no promise that a future version of ncdu will be able to
read the current format. There's also quite a few TODO's left.
dir_common.c: Don't display total size when it's not known

The total size isn't calculated when exporting to a file.
Support exporting to stdout while still allowing -u 2 to work
Added simple error checking & handling when exporting
Omit "dev" field in export when same as parent dir + "excluded" fix
Don't include "notreg" field for excluded/error'd files in export

+ some comment fixes.
path.c: Don't throw away remaining components after a symlink

This is a quick hack to fix http://dev.yorhel.nl/ncdu/bug/18.
path_real() is both rather unreadable, fragile, hard to maintain and a
bit inefficient. It wouldn't be too surprising if I introduced a new bug
with this commit...

*makes a note to do a proper rewrite of that code later on*
Added -f option to import an exported directory structure

This is the first working version. There's a few TODO's left.
dir_import.c: Put a limit on the recursion depth