users: the machine's users and groups by name, and the file that holds them.

  lib/machine/users.talc (machine users): reading the file, looking a user up by
                        name or number, a group likewise
  tools/users.talc      `users [path]`: the file as a table (USERS in the
                        environment, else /etc/users)
  users                 the file the vm's image carries at /etc/users:
                        root, and nobody else yet
  examples/users.talc   the library's test
  scripts/build.sh      builds bin/users
  scripts/regress.sh    the test, then `users` on the file here

Build and check:

  scripts/build.sh
  scripts/regress.sh

which need the installed toolchain (compiler on PATH).

THE FILE. The kernel knows users and groups as numbers and nothing else,
and so does the toolchain ((system identity)); this file gives them names.
One forms file, handed to whatever reads it -- sshd (../ssh) takes it as
-users <path> -- and nothing assumes where it is:

  (group "root" 0)
  (user "root" 0 (group 0) (home "/root") (shell "/bin/shell"))
  (user "alice" 1000 (group 100) (groups 100 998) (home "/home/alice") (shell "/bin/shell"))

A user is a name, a number, its group, other groups (none unless said),
a home and a shell; a group a name and a number. There is no password
field, because nothing in this system takes a password: sshd lets a user
in on a key in <home>/.ssh/authorized_keys and nothing else. A line that
is not understood refuses the whole file, as a .service file is refused,
so that a mistake is never a user quietly missing.

What the file does not do: make home directories (the image or the
person does), hold keys, or say who may log in (anyone named, with a key
in place).

Who reads it: sshd first. ../utilities' `owner` and `list -long` print
numbers today and could print names from here; the console could one day
log a named user in. Those are not done.