So it doesn't have to parse the INI file again.  Also, while lacme.conf
is world-readable by default, one might restrict permissions and add
private information in there, not realizing that everything, including
comments, will be readable by the client.

Also, always spawn the client with umask 0022 so a starting lacme(8)
with a restrictive umask doesn't impede serving challenge response
files.

This saves a round trip and provides a safeguard against malicious
clients.

Passing the JWA to the ACME client is required if we want to support
account keys other than RSA.  As of 0.7 both lacme-accountd(1) and
lacme(8) hardcode “RS256” (SHA256withRSA per RFC 7518 sec. A.1).

Passing the JWK thumbprint is handy as it gives more flexibility if RFC
8555 sec. 8.1 were to be updated with another digest algorithm (it's
currently hardcoded to SHA-256).  A single lacme-account(1) instance
might be used to sign requests from many clients, and it's easier to
upgrade a single ‘lacme-accountd’ than many ‘lacme’.  Moreover, in some
restricted environments lacme-accountd might hide the JWK from the
client to prevent ‘newAccount’ requests (such as contact updates);
passing its thumbprint is enough for ‘newOrder’ requests.