These are non-standard and specific to the version used in loader.  We
have some desire to recognize symlinks to avoid filtering out kernel
symlinks in the autodetection bits when they would be perfectly fine to
`load`.

This won't be usable right away, so any impending use will need to be
careful to account for nil.

Reported by:	leres

When lua_chown is used to call chown(2) internally, it first resolves
the user and/or group by calling the getpwnam_r(3) and getgrnam_r(3)
functions, respectively. However, although it checks for errors, it does
not check when entries are not found (which is not an error), which
means that the buffer will be set to NULL, and since lua_chown attempts
to access the NULL structure, it will receive a SIGSEGV signal.

Reviewed by:			imp@
Approved by:			imp@
Differential Revision:		https://reviews.freebsd.org/D55172

lposix is the last holdout of modules built into flua until we can fix
the module design to have the right parts require()able.  Address a
valid bug in lua_read() found at a higher WARNS and drop the override
entirely.  Some of the modules could possibly be re-evaluated.

Fixes:	c2caf3b3313 ("flua: lposix: add more useful functions [...]")
Reported by:	des
Reviewed by:	des
Sponsored by:	Klara, Inc.
Sponsored by:	NetApp, Inc.

- s/environnement/environment/
- s/interger/integer/

MFC after:	3 days

flua is a standalone third-party component that deserves its own
package.  In particular, this means things can use flua without
having to depend on FreeBSD-utilities, which will be useful as
more base utilities use flua.

This saves ~500kB in FreeBSD-utilities for systems which don't
need flua.

MFC after:	3 days
Reviewed by:	kevans
Sponsored by:	https://www.patreon.com/bsdivy
Differential Revision:	https://reviews.freebsd.org/D53161

Local tree pollution let this escape.  *sigh*.

Pointy hat:	kevans
Pointy hat:	kevans
Pointy hat:	kevans
Fixes:	9c7db0931d486ce ("flua: move lposix back into flua for now")

The real luaposix is structured differently, and our builtin version
tends to model that in its own special way.  Build it back in until we
get the shlib model just right to unbreak nuageinit, among other things.

This is a partial revert of the below-referenced commit; the other two
modules are simple, though, and were accurately split out.

Reported by:	markj
Fixes:	b11a5709ec2b6 ("flua: kick out the remaining builtin modules")

Bootstrap flua has some magic now to handle modules by building them in
and discovering them via linker sets.  This is slightly cleaner than
always building them in and baking them into loadedlibs for both
bootstrap and system flua.

Adjust the stand build now that these three libs have their own new
homes.

Reviewed by:	bapt, emaste
Differential Revision:	https://reviews.freebsd.org/D51891

This version builds every module into the flua binary itself, since all
of the bootstrap tools are built -DNO_SHARED.  As a result, we also
cannot dlsym(), so we can't really discover the names of our newly
builtin modules.  Instead, just build out a linker set with all of our
luaopen_*() functions to register everything up-front.

Building in all of the modules isn't strictly necessary, but it means
that we have an example of how to add a bootstrap module everywhere you
go and one doesn't need to consider whether bootstrap flua can use a
module when writing scripts.  On my build machine, the consequence on
our binary size is an increase from around 1.6M -> 1.9M, which isn't
really that bad.

.lua modules can install into their usual path below $WORLDTMP/legacy
and we'll pick them up automagically by way of the ctor that sets up
LUA_PATH early on.

This re-lands bootstrap module support with a more sensible subset, and
after having verified that it cross-builds fine on macOS and Linux -- we
cannot do libfreebsd on !FreeBSD because it's more system header
dependant.  We also need to bootstrap libmd to bring in libhash, and
libucl + libyaml.

Reviewed by:	bapt, emaste (both previous version)
Differential Revision:	https://reviews.freebsd.org/D51890

This reverts commit 1953a12ee2cde1afacb3e3f7612d89695c96e04f, because it
cannot work at all on macOS without more work, at a minimum.  We use
linker sets for module discovery, but we don't have a version of this
that works for mach-o at the moment.