Various style and variable name updates.  Result is used commonly as a catch-all reference to the object being worked on in a routine.  It's easier to understand the code if the return object is named after what's being constructed.  For instance, in the routine stacie_seed_key_derive() it's more informative to name the result "seed_key" instead of result.
Various style and variable name updates.  Result is used commonly as a
catch-all reference to the object being worked on in a routine.  It's
easier to understand the code if the return object is named after what's
being constructed.  For instance, in the routine stacie_seed_key_derive()
it's more informative to name the result "seed_key" instead of result.

st_append()
This commit was during a conversion of how st_append() is checked for
errors.  In general calls to st_append() were not being checked for errors.
Initially I added checks for every call to st_append() but the code swells
in size by 2x for no real gain.  As it turns out, it's safe to check only
the last call to st_append() in a chain or "cascade" of errrors.

log_pedantic() vs log_error()
Also, I'm making several passes through the code to uniformally set which
log levels are used for various error checking.  In general, in the case of
parameter sanitization I've elected to use log_pedantic calls with the
thought that parameter sanitization surprises are a result of the caller
not sending the correct data.  No harm, no foul.  Just a bail if the
parameters don't pass sanitization checks. log_pedantic() is also used
with the notion that we shouldn't be depending on the output from
log_pedantic to debug any brittle behavior from the server.  Assume that
log_pedantic could be commented out via a #define switch and you'll make
sense of when using log_pedantic is appropriate.

I use log_error in all cases where another provider call has resulted in
an error.  Assuming we're passing correct value to an external provider
routine (like openssl calls), we should not be getting errors.  Therefore
"log_error".  log_error is also used to report errors that indicate out of
heap memory conditions.  Not fatal, but not good.

I've yet to use log_critical, but I would in cases that I deem more serious
than log_error.  IMO, since log_fatal is missing from the facilities,
log_critical should be used in cases where the process is going to die no
matter what you do.

log messages
I prefer short, consise, non-wordy log statements.  The logging facility
implementation provides the file and line number of the log message so
there's no need to be any more verbose than what's minimally necessary.
Here, consistency in what's reported is more important than syntactically
correct, wordy prose.

Other updates in this large commit include:

Fixed:   stacie_hashed_key_derive() failed to error out when it detected
         the hash_input stringer failed to allocate.
Fixed:   none of the calls to st_append were being checked for failure.
         added checks for all.
Fixed:   there was basically no error checking in stacie_hashed_key_derive().
         Added error checking for all calls that could fail
Fixed:   stacie_hashed_token_derive failed to free result in the case of the
         allocation call to create hash_input stringer.
Fixed:   All calls to st_append() of the form a = st_append(a, b) are unsafe
         and will result in leaked heap memory in the event of st_append()
         returning an error.  NEVER use the code stucture:
         a = st_append(a, b) where the 'a' parameter will get overwritten!!!

lavabit/magma,lavabit/magma,lavabit/magma,lavabit/magma,lavabit/magma,lavabit/magma,lavabit/magma,lavabit/magma