nnn has been using `struct entry` to hold both file name as well as file info.

The design forces file names to be copied in the following cases:

 - swaps during file sort (nnn uses quicksort) applied after all the matching
   files are read (in no particular order; good old readdir()) into memory.
 - swaps during manual filtering. nnn moves non-matching entries below so they
   are not encountered twice resulting in fast filtering.

There were scopes for _massive_ improvements in this area. So I did what had to
be done - decouple the file names from `struct entry` and use a separate struct
to hold the names with the indices set when the files are added by opendir().

There was a hidden problem to this approach - nnn uses realloc() to allocate
memory for file information and realloc() may move the original pointer in mem
when it can't fit the new memory to the earlier pointer. To handle that the new
algorithm tracks the change in memory location and re-adjusts the existing dir
entry names when that happens; this too, without any copying!

Though the results seem pretty clean from a theoretical point of view and early
tests, we may uncover some bugs. However, the speed is just mind-blowing!

And the binary size remains the same too!!!

* Improve compatibility with OpenBSD

* Fix indefinite blocking

This reverts commit 1e859eb137.
We will use atool on OS X as well, it can be brewed easily.

...because you need to know where you are.

* Prevent nnn from waiting on open file process

* Add env var flag to not wait for child process when opening file

* Set nowait flag once to skip bit-or every time we open a file

* Add documentation for NNN_NOWAIT

Fix regression from 1e5a0b8c5b.

Check if the number of columns needed to print name exceeds the number of cols.
If it does, split the name str at the max number of columns available for name.
Conversion to wide char ensures the split is done at a valid codepoint.

The current patch adds some optimization as well:

- No more copying to an intermediate (global) string.
- If the name is shortened, escape chars are replaced only till the terminator.

In case of astral symbols like Devanagari matras multiple wide-char codepoints
occupy a single position/column. Positioning the cursor wrt. the actual number
of wide-characters in a wide-char string gets "visually incorrect".  The trick
is to calculate the correct number of columns needed to represent a fixed-size
wide-character string.

Relevant man pages:

1. wcswidth(3)
2. wctomb(3)
3. mblen(3)

Interesting links:

1. https://www.gnu.org/software/libc/manual/html_node/Non_002dreentrant-Character-Conversion.html
2. https://www.gnu.org/software/libc/manual/html_node/Shift-State.html
3. https://10hash.com/c-programming/uchar/
4. https://mathiasbynens.be/notes/javascript-unicode#accounting-for-astral-symbols

Example file names for test:

1. Malgudi Days - मालगुडी डेज - E05. Swami and Friends - स्वामी और उसके दोस्त (Part 5)
2. Eso eso aamar ghare eso ♫ এসো এসো আমার ঘরে এসো ♫ Swagatalakshmi Dasgupta
3. Führer

This reverts commit e8cf0dc663.

Very frequent with Devanagari scripts ('matra's)