Currently, when the darwin feature is enabled, Vim is unconditionally
linked against Cocoa, but that's too much for most of the cases.

For Tiny, os_macosx.m is excluded from the build to avoid link errors.
Then, if +multi_byte is not required for the build, we could exclude
os_mac_conv.c, too.  In other words, we don't need the empty
os_mac_conv.o to build an -multi_byte Vim.

As to Small, it's possible for Vim to have +clipboard with +multi_byte.
But that obviously compromises the interoperability of the clipboard.

This patch corrects those unreasonable things.

The following table summarizes the proposed changes:

                          (*1)
Feature             Clipboard   Extra Files             Framework
====================================================================
      -multi_byte   disabled    None                    None
tiny  --------------------------------------------------------------
      +multi_byte   disabled    os_mac_conv.c           CoreServices
--------------------------------------------------------------------
      -multi_byte   enabled     os_macosx.m             AppKit (*2)
                                os_mac_conv.c (vim#3)
small --------------------------------------------------------------
      +multi_byte   enabled     os_macosx.m             AppKit
                                os_mac_conv.c
--------------------------------------------------------------------

*1: For macOS, FEAT_CLIPBOARD is defined in vim.h for FEAT_SMALL.
*2: The linker automatically adds CoreServices in favor of AppKit.
*3: As mentioned above, +clipboard prefers +multi_byte.

Make the Mac-related feature list items easier to use by overhauling
macOS-relevant part of the build system.

The result can be skimmed easily only by reading the changes of a few
lines in runtime/doc/eval.txt.

With the changes, non-darwin Vim on macOS returns 1 for has('mac')
instead of 0.

To accomplish that, we could introduce a new compile flag to indicate
that the host system is macOS.  This is the easiest way to address the
issue, but there's a thing to note.

Why has non-darwin Vim returned 0 for has('mac')?  Why has that been
overlooked or remainted unfixed?

Personally, I think one of the reasons is that the transposition of
MACOS_X and MACOS_X_UNIX; the former is defined only if the latter is
defined.  While MACOS_X looks like covering all builds, it actually
doesn't.  It's a shorthand of MACOS_X_UNIX.  Very counter-intuitive.
MACOS_X should represent all the builds, and MACOS_X_UNIX should
represent the subset of MACOSX_X covering the darwin feature; by that,
the subset of non-darwin builds are represented even better.

Also, in src/configure.ac, what is referred to as "darwin" in our
documents is represented by the shell variable MACOSX, while in the
source code, the same notion is represented by MACOS_X_UNIX or MACOS_X
as its shorthand.  Context-dependent various symbols for the same single
notion.  Even if one can handle them with care, they are definitely very
confusing.  Preferably, they should be renamed so that people can work
with them comfortably.

Hence, it is true that adding a new flag solves the current problem
quite easily, but the whole situation will get more convoluted.  We need
an overhaul to get it back to be managable.

To accomplish that, this patch changes the semantics of the C macro
MACOS_X so that it will represent all the builds on macOS.

In theory, for darwin builds, the change shouldn't affect them except
for Tiny without multi_byte since it's identical with that for
non-darwin.

For non-darwin builds, we have to examine each occurance of MACOS_X,
MACOS_X_UNIX and MACOS in the source code one by one to determine what
exactly it has been meant for, and correct it without breaking darwin
builds if necesary.

Basically, patches following this commit are for that laborious task;
they will fix breakages or side effects resulting from the proposed
changes with this commit.

To begin with, they will fix breakages in the build system so that we
will run 'make' and 'make test' successfully for every possible build on
macOS.  After them, patches for fixing breakages or side effects which
are hard to catch will follow.

This is the only case where a darwin build falls back to that for
non-darwin (*1).

The cause of the breakages is that os_mac.h is now included even for
non-darwin builds, which results in some conflict with os_unix.h.

This issue could be solved quite easily by not including the header file
against non-darwin builds.

However, since non-darwin builds are those on macOS, people hardly see
why os_mac.h is excluded for them.  Rather, we should modify os_mac.h so
that it can coexist with os_unix.h in favor of the MACOS_X of the new
semantics.

To be more specific,

1.  Change around USE_CR: Without this, 'make test' would abort at a
    very early phase.
2.  Change around MAXPATHL: Without this, MAXPATHL and BASENAMELEN would
    conflict with those coming from os_unix.h.
3.  Change around SIGPROTOARG: Without this, HAVE_AVAIL_MEM would remain
    defined and cause a link error.

With this commit, 'make' and 'make test' should work for all dawrin
builds.

*1: The darwin feature was made on top of the previous build system
    where non-darwin was default.  Hence, although the current default
    builds are darwin, this sort of fallback, that restoring to
    non-default value, happens.

If MACOS_CONVERT is set, some of the object files are compiled to have
references to the functions defined in os_mac_conv.c which implement
part of the darwin feature.

Therefore, the macro shouldn't be defined for non-darwin builds.

With this commit, 'make' and 'make test' should work for all non-darwin
builds except 'make test' for the GUIs on XQuartz.

Since MACOS_X is now defined for non-darwin builds, MACOS is defined for
them, too.  This makes Test_set_guioptions() fail against the GUIs on
XQuartz.

To fix that, MACOSX is replaced with FEAT_GUI_MAC.  Obviously,
FEAT_GUI_MAC would be still more appropriate than MACOS here even if
the semantics of MACOS_X wasn't changed.  It is worth doing that for
it's own sake.

With this commit, 'make test' should work for all non-darwin builds, in
particular, the GUIs on XQuartz.

For non-darwin, MACOS_X is defined while MACOS_CONVERT is not.  Let
non-darwin rely only on libiconv.

Currently, the GUIs on XQuartz, which are all non-darwin, don't work
with the -f command-line option.  This commit fixes it.

Although if_python.c, if_python3.c and if_ruby.c refer to MACOS_X_UNIX,
at several places, none of them uses the functionality provided by
os_mac_conv.c or os_macosx.m, i.e., the darwin feature.  Rather, those
modules should be independent each other.

We should replace MACOS_X_UNIX with MACOS_X there.

All the occurrence of MACOS_X_UNIX should be replaced with MACOS_X since
they aren't used to specify the darwin feature.

Since this option is only for the Mac GUI, it's of no use for the GUIs
on XQuartz. Let E519 work for them, instead.

Conversion of LF into CR-LF is not specific to darwin alone.

Since MACOS_X_UNIXs here are irrelevant to the darwin feature, they
should have been MACOS_X.

The condition defined(MACOS) already appears to define FEAT_HUGE.

The reason is obvious.

sys/errno.h defines EILSEQ if __DARWIN_C_LEVEL >= __DARWIN_C_FULL, and
the condition holds true for newer Mac OS X.

After all, MACOS_X_UNIX is meant for taking advantage of macOS-specific
API rather than for making use of Unix-proper API.

Probably, this is the last piece to prevent the lasting misunderstanding
and confusion.

Still, the name remains confusing because Darwin is the name of the
kernal of macOS.  Hopefully, someday someone will give a better name to
what we call "the darwin feature of Vim" today.

Although the support for the platform in question has been discontinued
since Vim 7, there're still remnants of it.  Remove them.

N.B. At some places, MAC_OS_CLASSIC has been used.  This may be a typo
or a direct reference to a macro defined in a system header file.
Either way, it is supposed to share the same fate with MACOS_CLASSIC.

Now that MACOS_CLASSIC is completely left out, the condition
"defined(MACOS) && !defined(MACOS_X)" is identically false.  Remove the
code blocks subject to the condition.

Also, if_ruby.c has had the macro 'macintosh' which is considered a
synonym for MAC_OS_CLASSIC.  Naturally, that will be removed, too.

Finally, macOS has <sys/ioctl.h>, and the third parameter of open(2) is
varargs.  Adjust pty.c accordingly.

It is misleading that MACOS sounds like it still covers MAC OS Classic.

Those two MACOSs are a wrong substitute for MACOS_CLASSIC, since Mac OS
X has the global environ(7) variable.

These are the pre-defined macros of compilers for Mac OS Classic.

That #undef is unnecessary for the recent versions.

The last change to the block is dated 2008-08-09, and the latest Mac OS
X those days was 10.5.  So...

Mac OS X has sgtty.h.

Seems like the macro MACOS here is actually meant for MACOS_CLASSIC.
No reason to exclude the block for Mac OS X.

Now that none of MACOSs that are meant for MACOS_CLASSIC remains,
we can safely replace MACOS with MACOS_X.

For non-darwin Tiny and Small builds for Mac OS X having XQuartz
installed, the resulting executable is linked against X11 libraries
since mblen() is inadvertently replaced with _Xmblen().

To fix that, add a check for mblen() to configure.ac, add a check for
HAVE_MBLEN to after the checks for __amigaos4__ and __ANDROID__, move
the preprocessor block for replacing mblen() with _Xmblen() to the place
where Xlocale.h is included in order to make the code cleaner, and
correct the indentation level of a #if block to reflect the nesting
depth correctly.

This commit should also fixes unexpected X11 dependency seen in some
multibyte-enabled builds on other platforms.

…Small

Now that MACOS_X is alwayed defined for any macOS builds, some #if
statements are evaluated to be constant, and thus redundant.  Reduce
them.