We don't document exit code
We sometimes don't care for the return of a function
(e.g. 0 is the same as 1, though 1 indicates to the
developer that something should potentially be handled)

As for the change to list_add I don't actually see
how it could fail (attaching to a file, or creating one?)
and if it does is _very_ unexpected situations we
want it to fail louder

This allow us to, at the same time:

* create the file
* return from inner functions, for exiting purposes
* writing to stderr
  * without the output being consumed by sub-shells

In certain situations, I was getting execution stopping
silently (e.g. 404 on curl calls) because we're using
shortcuts such as || true, and || return, or even || exit
without prior error messages, which this commit attempts
to fix

When it's clear to do so, instead of bubbling up
return values until we're ready to exit

Reduces the number of functions

assert_ is ok to use, but then we have scattered exit
vs. return which makes it harder to reason on

Also, we move `assert_build_name_unused` to
`is_build_name_used` to avoid double negation

If the function is exiting we call exit
If it's returning we prefer return (and exiting higher up)

Previous changes allow us to prevent two calls to
`get_active_path` while making sure:

* we exit on error
* always continue to function calls otherwise
  (we reduce a nesting level with this change)

Prefer failure with controlled messages

We always show_build_logfile with a message
  then autoclean with a file "pointer"

With a function it'll be easier to not forget how to
do cleanup, if the function changes in the future

Due to the recent changes we started exiting with 1 on
_kerl status_ when no installation is active

I think errors should always exit with a non-0 status

... but you might not always show an error when you exit
with a non-0 status (this is context dependent)