Make linking against ncursesw opt-in

[mptre]

I've always found it odd that pick favors linking against ncursesw if
present instead of curses. This gets even more interesting on my machine
where the ncursesw library is present but not the headers. This means in
practice: the curses headers are used but later linked against ncursesw.
However, it does work since ncursesw implements the same API as curses.

My proposal is to make linking against ncursesw a opt-in feature since
the more common curses library should be favored if available.

This patch adds a --{with,without}-ncursesw option to the configure
command, which defaults to false. The change is therefore breaking in
sense that users with only ncursesw available has to pass the new option
while running configure. A reasonable compromise in my opinion since
less implicit dependency resolving is a good thing. Worth mention: the
major of the users will not notice this change if curses is available
(most likely).

If I where to decide I would go even further and trust the user: if the
ncursesw option is given, assume the both headers and libraries are
present. Much of the autoconf verification could then be dropped -> less
code to maintain.

Left-over notes:

• I'm planning on running Travis with and without ncursesw
• Any advice or convention on how the format all the parenthesis and
  brackets inside configure.ac would be appreciated

Thoughts @calleerlandsson and @mike-burns?

[mike-burns]

For history, see #49.

[calleluks]

Great initiative, @mptre! Thanks for always looking for ways to simplify and improve the code base.

I'm not entirely sure why one would favor linking against any of curses, ncurses, or ncursesw over the other, other than it being the only one available on the system. Are there other differences than the fact that ncursesw supports wide chars?

My understanding of the changes in #49 is that they were intended to support systems that only had ncursesw installed.

Unless there are reasons to link against a specific version, what do you think about try linking to any of them available favoring the simplest one if multiple are available? I'm guessing this would be curses > ncurses, ncursesw?

I think the formatting looks fine.

@eavgerinos what are your thoughts on these changes and ideas?

[calleluks]

Just curious: why "x$with_ncursesw" != xno and not "$with_ncursesw" != no?

[calleluks]

The old AC_SEARCH_LIBS mentioned ncurses instead of curses. I'm not sure what the differences between them are.

[mptre]

I'm not entirely sure why one would favor linking against any of
curses, ncurses, or ncursesw over the other, other than it being
the only one available on the system. Are there other differences than
the fact that ncursesw supports wide chars?

We don't use any features of ncurses at this point. But if curses is not
available, the ncurses implementation of curses is used.

Unless there are reasons to link against a specific version, what do
you think about try linking to any of them available favoring the
simplest one if multiple are available? I'm guessing this would be
curses > ncurses, ncursesw?

I like this idea. Less knobs to fiddle with is a good thing. See the
updated commit. We still need to define HAVE_NCURSESW_H in order to
include the correct headers.

Just curious: why "x$with_ncursesw" != xno and not "$with_ncursesw" != no?

Adopted the style in the autoconf manual.

The old AC_SEARCH_LIBS mentioned ncurses instead of curses. I'm
not sure what the differences between them are.

Using curses is sufficient for pick. We could add ncurses as a fallback
prior to ncursesw if people can't build on some platforms.

[calleluks]

Sounds and looks great to me!

[mptre]

Thanks, merged.