This addresses the changes requested by Rycieos at #702.
To summarize:
The flag -v exists since first version of sudo and we can't find a
reason why to use true.

This commit changes the default behaviour of sudo detection to use
sudo -v instead of executing true.

Validation of sudo credentials is done by invoking a command (true).
This means that, if the user has sudo credentials, a root session is
opened and then closed. Potentially generating two PAM messages plus the
sudo line for true being executed as root.

This commit adds an option to use the validate command (sudo -v) to test
for credentials.
Validate command DOES NOT open a session and does not log anything on
success.
It still logs "a password is required" in case of failure but those
lines are easier to filter out searching for COMMAND=validate.

I've opted for adding LP_USE_SUDO_VALIDATE instead of replacing the
default behaviour because I'm not sure if -v is on every system.
The default value is 0: using the old behaviour (execute true).

Mercurial is written in Python 2, so it was always slow. There is work
ongoing to rewrite it in Rust, but as the replacement is not at feature
pairity yet, they are shipping the binary as 'rhg'. Since some might
want to use different binaries for different things, give a config
option to pick which binary to use for prompt data gathering.

Resolves #701

Without these functions defined, each prompt invocation would force the
shell to check if the command was valid, and generate an error message
if it was not. We know that it won't be, so we can shortcut that by
setting it as such.

More importantly, if the Bash function command_not_found_handle() is
set, it will be executed for each function that is not set. For Git or
HG, this is only one. But for SVN, it is enough to lock the prompt for a
while.

Fixes #696

If no current context was set and the KUBE_NAMESPACE feature was
enabled, kubectl would print an error message, which would leak through
to the terminal.

Fixes #695

With the removal of the command -v check, anything returned on stdout
would make acpi be a valid backend. This can happen in the
command_not_found_handle() function is defined.

Also don't pick a backend if the data function returns an error code.

Further strictness could be to check that the string returned is a valid
int, but that is probably overkill.

Fixes #690

Zsh by default will error if a glob matches nothing (a smart default).
We need it to not error, and even better, to not use the Bash default of
using the pattern. Set nullglob to expand it to nothing.

Don't set the Bash version of nullglob in liquidprompt, since Bash
doesn't do local options well, and not at all until version 4.4. It is
safe to expand to a single string with the "*" in it, since the first
check we do is for the file existing, which it will not.

Add the sysfs power supply interface to the external-tool-tester.sh.

Add sysfs function, tests, and documentation.
Set sysfs method as default.
Remove LP_BATTERY_ID from __lp_battery_acpi() as unreliable.

Co-authored-by: Mark Vander Stel <mvndrstl@gmail.com>

When running in non-interactive environments sometimes the TERM is set to 'unknown' rather than being unset, e.g. https://askubuntu.com/questions/1091553/how-do-i-fix-error-opening-terminal-unknown-on-ubuntu-server

When ACPI returns multiple batteries, and not all of them related to laptop
battery, this option can be used to specify which battery to be used for
status information. Example of this is Logitech Unifying Receiver, returning
battery information for keyboard/mouse.

Broken in commit 4c81ef40, if a
temperature was ever recorded above the threshold, _lp_temperature()
would always return that high value, never resetting.

Fixes #686

[bash-preexec](https://github.com/rcaloras/bash-preexec) "provides
preexec and precmd hook functions for Bash in the style of Zsh".

Unfortunately, it interferes with `trap DEBUG` and `PROMPT_COMMAND`
behavior used by `LP_ENABLE_ERROR` and `LP_ENABLE_RUNTIME`.

Fortunately, since liquidprompt already supports add-zsh-hook behavior,
we can use those hooks as guides to where we should add hooks for
bash-preexec.

These hooks get set if __bp_imported is "defined"; this is set by
bash.

Note on tests/test_bash_preexec.sh: test functions' contents are wrapped
in  `( ... )` subshells so that the sourcing and installation of
bash-preexec is confined to that test and does not pollute others.

Don't know why I didn't think of this before. While contexts can
contain any character, namespaces are limited to the normal DNS name
rules, and so we can parse on the last instance of a delimiting
character found.

Add data gathering for the configured default namespace of the current
kubectl context. Display that data as a string directly after the
context string, separated by a colon.

While this is a separate chunk of data from the context, it is actually
part of the context definition, and so it makes sense to display it
along with the context.

While most Kubernetes objects are subject to the strict DNS name
restrictions, kubectl contexts never have their name server-side, and so
do not have the same restrictions. This means a context name can include
any characters, meaning we have no safe way to parse it out of a data
string. I wanted to use:

line=$(kubectl config view --minify --output 'jsonpath={.current-context}{" "}{..namespace}')
IFS=' ' read kubernetes_context kubernetes_namespace <<<"$line"

But since spaces can be in a context name, this would break.

Hooks have always been a mess. There was no organization when they were
added, as when the project first started there was no need for them.

To make things consistent, break out disabling hooks into
__lp_disable_hooks(), and make prompt_on() be the enabler of hooks. Then
have lp_activate() disable hooks at the start, and enable hooks at the
end.

Some small changes around how state is detected, but no functional
difference here.

Based on the work done in ecdde384, the
prompt_bang and prompt_subst options, which handle '!' and '$'/'`'
characters respectively, can be left untouched. When running
__lp_escape(), those options are checked, and if set, their characters
are escaped.

prompt_percent however, must still be enabled always. The shell sequence
escapes, '%{' and '%}' only work when the option is enabled. Maybe
someday we can detect when the option is off and disable all terminal
formatting, but it doesn't seem worth the effort.

Backslashes must be escaped even on Zsh to prevent confusion with a
backslash directly preceding a character that would give is special
meaning.

For some reason, Bash ignores a '\$' sequence when the promptvars option
is off, printing it as '$'. It does not do the same for a backtick
escaped: '\`' is printed as '\`'. To prevent this issue, detect if the
option is on, and if so, escape both '$' and '`'.

Running 'shopt' is actually faster than either a [[ ]] or (( ))
expression.

Extension to #496 to add [AWS Vault](https://github.com/99designs/aws-vault)
support. AWS Vault does not set the AWS_PROFILE/AWS_DEFAULT_PROFILE
variables, but does add AWS_VAULT. Since this is philosophically the
same as showing an AWS profile on the prompt, I simply added AWS_VAULT
to the detection chain.

Also remove some trailing space.

Closes: nojhan/liquidprompt#675

This was missed in the PR for the Ruby Virtualenv section.
The order in the docs for Terraform and Kubecontext was backwards from
the order in the code.
Moved parts of the PS1 building to different lines to make it easier to
read and add new sections.

Resolves #676

LP_KUBECONTEXT_DELIMITER_SUFFIX removes a suffix (dev-cluster and - becomes ->
dev). But sometimes the boilerplate part is a prefix, as when using AWS
EKS (Elastic Kubernetes Service).

`aws eks update-kubeconfig --name $CLUSTER_NAME` sets the cluster's ARN
as the context name, most of which is boilerplate:
`arn:aws:eks:$REGION:$ACCOUNT_ID:cluster/$CLUSTER_NAME`.

This breaks several VCS functions (mercurial, fossil, svn).

Rarely, sensors or acpi can return no temperature data. In this case,
the data function would return false and 0, but the detect function
would error if set -u was enabled.

Harden all of the four temperature functions against this, and greatly
increase the test coverage to cover these four functions, as well as
adding a specific case for the tools returning no data.

This also allows for the temperature functions to return values less
than 0, if somehow a device has all temp sensors returning less than
that.

Mention in the function documentation that it is possible for the
function to return a not set string.

Fixes 670

Fixes https://github.com/nojhan/liquidprompt/issues/600.

Zsh 5.0 continues to be a huge pain. As noted in the shell wiki, all
variables assigned to another variable as part of a 'local' or 'typeset'
line must be quoted, or things will break. The reason I caught these
many instances was a failing test on Zsh-5.0.8 because of the bad line
in __lp_pwd_tilde().

Parameter substitution is (like most standards) weakly defined, and here
is a case where it was not tested on Zsh. Simple fix of wrapping the
whole string (the '(' was the bad character) in quotes.

Also add a test case to catch a regression.

Fixes #667

When the LP_COLORMAP config option contained a first element that was
the empty string, lp_activate() would think it was empty, and set
LP_COLORMAP back to the default value.

This was identified by @milouse in a comment here:
https://github.com/nojhan/liquidprompt/pull/628#discussion_r611182040

The issue is not severe, as any value set in the config will always be
taken (as it is set last). But a value set in the environment, either
manually or in a shell RC file would be overridden (as long as the first
element was the empty string).

Commit e121179d has a good explaination
of why the ${array[@]+"${array[@]}"} form is used. This unfortunately
must be used _anywhere_ an array could be empty or have any empty
strings as values.

Fixes: https://github.com/nojhan/liquidprompt/issues/249

The problem is simple enough: the extra backslashes or percents that
__lp_escape() adds show up in the title, as the title is changed in the
previous commit to no longer be printed as part of PS1. The fix is not
so simple.

This patch adds "raw" copy of the data strings for username, hostname,
and current path with no color or shell character escaping. This is
designed for putting into the terminal title, but it could also be used
for comparisons. lp_path_format() already had a no formatting return var
in lp_path, but now it is not shell escaped.

The title is changed from duplicating the prompt to instead showing just
the core bits in the central brackets: username, hostname, current path,
followed by the prompt mark. As well as the user prefix, postfix, and
MARK_PREFIX. This is a change from the long standing default, but it is
customizable both by themes and users, and I have long seen complaints
of the current title layout being less than helpful.

There is one small issue though: to prevent LP_PS1_PREFIX,
LP_PS1_POSTFIX, and LP_MARK_PREFIX that have color from messing up the
title, the whole title string is still passed into lp_formatted_title()
to strip color out. This is less than ideal, but faster than treating
those 3 variables by themselves.

Rationale:

* In general, it is not proper for liquidprompt to change shell
  options that it does not absolutely have to change.

* LP_PS1_{PREFIX,POSTFIX} are a thing, and are in fact an effective
  means to combine liquidprompt with other prompt-touching logics
  (such as emacs-vterm).  So it is not good to prevent those other
  logics from actually working.

This commit restores the bash version of __lp_escape to what it did
prior to 62f02708 (escaping dollar signs in addition to backslashes)
and removes all interference with the promptvars shell option.

NOTE: I don't know much about shells other than bash, so left the
parallel logic for zsh as is.

This feature depends on the removal of the prompt escape sequences that
came before. Part of that is the removal of adding the title to $PS1:
now it is just print to the screen. This could improve speed slightly,
as the shell doesn't need to parse that text. But it does prevent usage
of prompt escape codes in the title.

Which causes a rare issue where __lp_escape() adds duplicate backslashes
or percents to escape a string for the prompt, but now are not needed in
the title. It will just print double in the title, so it isn't a huge
issue, but is something that should be fixed. I'm not sure how to handle
it though, since the current architecture requires escaping the strings
before formatting is added to them.

I also needed to rework how the runtime feature was handled, since it
monopolized the DEBUG trap in Bash. Now it can handle multiple features
that need to run after the user has submitted the command, but before it
runs.

The feature itself is simple: lookup the latest command in the history,
and print the normal title postpended by that command to the screen,
formatted as a terminal title. Note that Bash's $BASH_COMMAND is not
great, as it only contains the current _command_, not the whole command
line.

Resolves #609

This was forgotten before.

This was added in commit 74e14fe0. I
don't understand why, except that maybe a single backslash display would
look like an escape code for a control character, like \n. But that is
not the case for Bash, so why the difference?

Zsh only uses percents (%) to escape things in the prompt, where Bash
only uses bashslashes. This changes makes the same input string print
the same way in the prompt for both shells.

Again further work on #651. This time it is simple: both Bash and Zsh
set the exact same hostname that they use for their prompt escape
sequences into HOSTNAME and HOST, respectively.

Then it is a simple matter to replicate their "short" version by
truncating the string to the first period.

Another replacement for #651, this one was mostly simple. Unfortunately,
not all shells set an environment variable for user. Zsh always sets
USERNAME, but neither Bash nor Zsh set USER. login(1) does however, so
it _should_ always be set. See https://unix.stackexchange.com/a/76356/421569
for some good info.

Fall back to id -nu just in case the variables don't work. I don't know
how portable that command is, but since it is a backup, it should be
fine.

By calling date(1), another shell prompt escape sequence is removed.
This also allows for custom formatting strings.
Add and update docs for time functions.

Resolves #281

Part of #651, this removes a shell prompt escape string, making it
easier to work with terminal titles, as well as making it possible to
customize the prompt mark for the root user. This patch does not do
that, as the functionality has remained the same, but it would now be
possible to add a LP_MARK_ROOT.

This patch should have no functional difference, as the checks that Bash
and Zsh did in the prompt escape are exactly the same that Liquidprompt
is doing: comparing EUID to 0.

This will add `[profile_name]` to the prompt should it find either
`AWS_PROFILE` or `AWS_DEFAULT_PROFILE` set in the environment.

This is useful when switching between different AWS profiles and
working with multiple accounts.

Add a data source to get the current Kubernetes context. Includes a
mechanism for truncating the context to the first matching character,
configurable.

The data source is disabled by default. The truncation is also disabled
by default (disabled by setting the config option to the empty string).

Add a default theme function to format the context like the other
development environments.