I added some option values for --temacs to facilitate interrogating a
bootstrap build of emacs before dumping, e.g. for convenient use in a
Makefile.  Then I started wondering what would happen if I called
dump-emacs-portable from that state, say, for creating a minimal
stand-alone (byte and/or native) compiler dump and executable.  To
further facilitate such stand-alone programs (e.g. an elisp
lsp-server), I hacked the "fingerprint" feature to create a fixed area
for writing hard-coded configuration options into the (or a copy of
the) executable file, such as a default basename for the dump file or
a "shim" lisp program that will be run before the startup procedure
from the dump file.

The new options for temacs are
* --temacs=eval-args  - evaluates all remaining command line arguments
as programs (like load or eval-buffer).
* --temacs=eval-stdin - evaluates the stdin stream as a program.
* --temacs=eval  - first eval-args, then eval-stdin

These modes put emacs in "noneditor mode" (really noninteractive)
which sets up a simple catchall handler and runs the program(s) from
the specified sources.  All other options are ignored.

When eval-args or eval is specified, the lisp program will not have
access to the command line arguments.  If eval-stdin is specified, the
usual lisp variable for command-line arguments holds a list of all
arguments.

If a dump file is created from one of these modes, a post-load hook is
added to ensure that emacs is in noneditor mode.  If "noneditor" is
defined in the dumpfile, that will be called as the "main" program to
execute, and emacs will exit when it returns.  If noneditor is not
defined, then emacs behaves as if "eval-stdin" was specified.  In
either case, the command-line arguments are stored as a list for use
of the program.

Since the emacs executable in noneditor mode ignores all command-line
options, I've added a field of flags that can be configured by
make-fingerprint or from lisp functions for creating a "customized
emacs executable".  Currently the flags only specify whether the
executable is to start in noneditor mode, and if so, what sources of
commands it should us (args, stdin, both or neither), whether to run a
shim lisp program, and to run "bare" (i.e. no dump file or loadup).
This feature is mostly to make up for the usual option processing
being suppressed, so it would make sense to add support for other
useful options that are handled in C code.  I believe that would only
be the two "daemon" mode options.  noneditor mode is for creating
dedicated emacs-lisp programs, so site-lisp directories are not
configured, and user/site init files are ignored.

The following new lisp functions are defined:

* (get-emacs-executable-custom-settings)
* (get-emacs-executable-fingerprint-data EMACS_EXE_FILENAME &optional
MAX_SHIM_SIZE)
* (make-custom-emacs-exectuable OUTFILE &optional FLAG_LIST BASENAME
SHIM HASH EMACS_EXE_FILENAME)

The flag bits are reported and set using symbolic representations and
their complements:
* 'noneditor / 'editor
* 'stdin / 'nostdin
* 'args or 'command-line-args / 'noargs
* 'bare / 'not-bare
* 'shim / 'noshim
When setting the options, the options will be processed sequentially
starting with the existing flags in the specified executable.  The
symbol 'clear turns all flags at whatever point in the sequence it is
processed.
The "HASH" argument may be
* nil or 'original - leave fingerprint as is
* 'reset or 'pristine - set the fingerprint to the default from libgnu
* 'custom - set the fingerprint to its pristine value, then set the
specified options, then calculate the fingerprint to write in the
executable.
* 'standard - set the fingerprint to its pristine value and zero the
storage area, calculate the fingerprint from that state before setting
the configuration data.

SHIM is either
* 'original - keep existing shim string
* 'reset or 'clear - zero the shim string
* An s-expression that is converted to a string via prin1-to-string

make-fingerprint has been augmented with options for displaying and
setting the storage area associated with the fingerprint.  I
implemented yet-another-string-literal syntax for specifying binary
values is a shell/Makefile friendly format.  The library code for
parsing that format can be tested with the program
parse-string-literal in lib/test.

I still haven't actually *dumped* a program in noneditor mode, or
determined what the shortest build of a standalone compiler for use in
the build process (or for async compiling) is.

It does not break any existing tests (that weren't expected) - which
considering it is mostly orthogonal to existing code, it really
shouldn't.  Note I have applied my patch for a reentrant reader, but
it probably isn't completely necessary.  This is nominally my original
impetus for that chunk of work.

I'm curious if anyone else is interested in these features.  I'd like
to be able to at least load files encoded in emacs-internal (or
compatible) into a buffer without loading all of mule/international
support for a shorter bootstrap compiler build, depending on how much
of a dent in dump-file size/build time it would make.  I'm sure
loading all 125-150 files from loadup is not really necessary just to
be able read lisp files and produce compiled files.

Lynn