Implement uniform password "encryption/decryption" mechanism

Many of Log4j components require a password attribute (e.g. `SslConfiguration`, `JdbcAppender`, etc.), but only [`BasicAuthorizationProvider`](https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/util/BasicAuthorizationProvider) uses a pluggable [`PasswordDecryptor`](https://logging.apache.org/log4j/2.x/javadoc/log4j-core/org/apache/logging/log4j/core/util/PasswordDecryptor) service to interpret the meaning of the password field.

I would propose to extend the usage of this service to all password fields and provide two implementations of `PasswordDecryptor`:

* one implementation that interprets the "password" as the path to a file that contains the password,
* one implementation that interprets the "password" as the name of an environment variable that contains the password.

This would allow us to deprecate configuration properties such as `log4j2.keyStorePasswordFile` and `log4j2.keyStorePasswordEnvironmentVariable`.

**Disclaimer**: I am fully aware that a real password encryption/decryption mechanism doesn't make sense, since configuration sources must be trusted anyway and I totally agree with the remarks about password encryption on [Tomcat's Wiki](https://cwiki.apache.org/confluence/display/TOMCAT/Password).

However some auditors and analysis tools might have problems with plain text passwords in configuration files and this feature will allow users to provide their own workarounds.