Logging lifecycle

[zdykstra]

This PR is an attempt to make logging play a more focused role in the ZBM ecosystem. Various components would correctly catch and log an error through zerror(), but unless you know how to look for them, they were entirely hidden from view. As such, I attempted to meet the following goals:

• Where an error is critical, (kexec, duplicating a BE), show a prompt and log an error
• For all other error conditions, log an error with enough contextual information
• When an error is generated, show an indicator on the main screen
• Allow the error log to be viewed on any selector screen via MOD-L

In addition to the error log integrations, I made a pass through virtually every function in zfsbootmenu-lib.sh. Where positional parameters are non-optional in a function call, a test for empty is performed for each parameter. If the parameter is empty, an error is logged and and the function returns. Some functions had a check / silent return, others did not. They've all been normalized.

I've tested the behavior with an x86_64 BE in a ppc64le VM to confirm kexec and chroot error handling.

Are there any other error conditions that should warrant a timed_prompt, or should the current usage be pared back?

One side effect of this work is that the heavy usage of zdebug() does have a performance impact, so booting ZBM with loglevel=7should now only be done if you actually need debug level logging. Nothing is free.

[ahesford]

This looks good in general. We can run it through some more rigorous testing as part of the next release.