Generalise libcompat to be a list rather than a single option

[jrtc27]

Summary

Whilst the kernel can support any number of COMPAT_FOO, world can only
build a single libfoo. Upstream this isn't such an issue, since the only
option is lib32 anyway, but downstreams, such as CheriBSD, may wish to
support multiple at the same time. Thus, adjust the top-level Makefiles
to turn _LIBCOMPAT into a _LIBCOMPATS list that gets iterated over, and
adjust bsd.compat.mk to support this use-case.

For the normal NEED_COMPAT/WANT_COMPAT case, LIBCOMPATFOO remain set and
refer to the requested compat's, preserving the current interface. For
the top-level Makefiles those variables are no longer set (since there
is no longer "the" compat) and only the per-compat ones are available.

[imp]

Makefile.inc1

854

How do others get added?

1183

Where does through lowercase version of this get set?

[jrtc27]

Makefile.inc1

854

.if ${MK_LIB64} == "yes"
_LIBCOMPATS+=	64
.endif

etc; I actually tested this by adding a (pointless) lib64 to amd64 in https://github.com/jrtc27/freebsd-src/commit/b5123f22133f09451edd04ef1a3fca4ff2feb547

1183

Line 107 of bsd.compat.mk (akin to how line 102 used to set libcompat singular)

[jhb]

That is less painful than I thought it was going to be.

[jrtc27]

• Fix build for compat-less arches
• Fix WMAKE_TGTS filtering, including for universe-toolchain

(tinderbox now succeeds)

[jrtc27]

Ping for the updated diff?

[imp]

My questions are answered. Don't see anything else noteworthy