I see some distribution inference rules that seemed to pop up
several times. The script seems to be useful in several places,
but I have not deduplicated the code yet. That would involve
changes that are out of scope.

Deployment would be easier if `pa.sh` helped users with
`PASH_TOP` and a default `~/.pash_init`.

I saw scripts to modify the user's rcfiles (which is not ideal, imo).
With process substitution, the process for setting `PASH_TOP` is
a little nicer.

    $ cd "$(find ~ -type f pa.sh | xargs -n 1 dirname | head -n 1)"
    $ ./pa.sh
    # Add this to your shell configuration.

      export PASH_TOP='/home/sage/prj/pash'
      export PATH="$PASH_TOP:$PATH"

    # If your shell supports process substitution (bash, zsh, etc.)
    # run `. <(./pa.sh)` to use PaSh in this shell.

The key benefit for deployment is that you can simply instruct a user to
actually start using PaSh and follow its instructions, as opposed to adding
installation steps.

Since this is Bash, I use `return` to prevent accidental
execution of further instructions when `pa.sh` is sourced.

Some code only calls `make` with no target specified. No `autogen.sh`,
`configure`, etc.

Maybe that's fine for the runtime, but it's not enough for the `libdash`
derivative. I wonder if there's a different script that I haven't seen
yet that does this better.

Distribution-specifics were split between two spots in
scripts/package/tools/build. Reason being the file name was
computed separately from the flags.

- Add functions for distribution specifics.
- Default to 'now' as a version (helpful for quick iteration)

I've been told that fixing `pa.sh`'s fallback value for `PASH_TOP` would
cause performance penalties. This patch updates `PASH_TOP` in `pa.sh` as
a post-installation step for packages

Verified with existing Docker images, but do not assume 100%
compatibility with all package managers. Unsure if there are special
rules out there that prevent an installer writing to a file extracted
from a package.

Add GitHub Actions paragraph content