share/mk: support for "single" group options

Support group options where 1 of n values will be selected (or a default
value will be used). After processing, an OPT_FOO will be set to one
value from __FOO_OPTIONS for each FOO in __SINGLE_OPTIONS. If the user
sets FOO that value will be used, otherwise __FOO_DEFAULT will be used.

Options that don't work an a particular system can be remapped to an
alternative using BROKEN_SINGLE_OPTIONS which can be set to a list of
3-tuples of the form:
OPTION broken_value replacement_value

This is somewhat inspired by OPTIONS_SINGLE from ports, but the
structure is quite different with a per-option variable in the style of
MK_FOO={yes,no}.

Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D41659

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

Warn about nonfunctional WITHOUT options

Print a warning if we try to WITHOUT_ an option which is marked as
"required" (and forced on).

Suggested by: emaste, imp
Reviewed by: emaste, imp
Differential Revision: https://reviews.freebsd.org/D40613

bsd.mkopt.mk: Add REQUIRED_OPTIONS list

Options on this list will be forced to 'yes'. This is intended for use
as a transitional measure when an option is ceasing to be optional,
before all of the associated make logic is removed.

Differential Revision: https://reviews.freebsd.org/D40590

Remove more quotes around Makefile .error/.warn/.info strings.

Reviewed by: imp, emaste
Differential Revision: https://reviews.freebsd.org/D34175

insetad -> instead

mk: WITH_FOO=no now generates a warning

Many people are used to gnu configure's behavior of changing
--with-foo=no to --without-foo. At the same time, several folks have
WITH_FOO=no in their config files to enable this ironic form of the
option because of an old meme from IRC, a mailing list or the forums (I
forget which). Add a warning to allow to alert people w/o breaking POLA.

Reviewed by: allanjude, bdrewery, manu
MFC After: 2 weeks
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D30684

Document logic for __DEFAULT_DEPENDENT_OPTIONS

Reviewed by: stevek
Differential Revision: https://reviews.freebsd.org/D21640

Appy := to dependent opts once value determined.

This is needed to fix output from 'make showconfig'

Add support for dependent options

Reviewed by: imp

Add support for __DEFAULT_DEPENDENT_OPTIONS

Revert the __ALWAYS_NO stuff. It had already been committed as BROKEN.

Add support for specifying unsupported / broken options that override
any defaults or user specified actions on the command line. This would
be useful for specifying features that are always broken or that
cannot make sense on a specific architecture, like ACPI on pc98 or
EISA on !i386 (!x86 usage of EISA is broken and there's no supported
hardware that could have it in any event). Any items in
__ALWAYS_NO_OPTIONS are forced to "no" regardless of other settings.

Differential Revision: https://reviews.freebsd.org/D2011

Add support for specifying unsupported / broken options that override
any defaults or user specified actions on the command line. This would
be useful for specifying features that are always broken or that
cannot make sense on a specific architecture, like ACPI on pc98 or
EISA on !i386 (!x86 usage of EISA is broken and there's no supported
hardware that could have it in any event). Any items in
BROKEN_OPTIONS are forced to "no" regardless of other settings.
Clients are expected change BROKEN_OPTIONS with +=. It will not
be unset, so other parts of the build system can have visibility
into the options that are broken on this platform, though this
should be very rare.

Differential Revision: https://reviews.freebsd.org/D2009

Enforce that MK_foo options shall be either "yes" or "no" and nothing
else.

fix spelling of DEFAULT in comments...

Spell always the more traditional way.

Put bsd.own.mk back in the list, and take src.opts.mk out.
Fix a silly typo.

Fix a typo make should have complained about.

Submitted by: Mark Johnston

[1] Make WITHOUT_FOO alway trump WITH_FOO, regardless of the system
default. This restores more of the historical expectations that
were broken when we started disallowing both WITH_FOO and
WITHOUT_FOO to be defined.
[2] Document this new behavior, and improve the documentation in
general here.

Submitted by: sjg@ [1].

WITHOUT always wins

Reviewed by: imp

Move the generic part of bsd.opts.mk into bsd.mkopts.mk to allow for
the WITH/WITHOUT_FOO -> MK_FOO={yes,no} stuff to be used elsewhere.