Allow to programatically set the user password

Use cases

• @unrznbl started an amazing automated testing of postmarketOS on the lg-hammerhead project, so we can quickly find and fix regressions there, and needs to do pmbootstrap install automatically with a preconfigured password.
• @MartijnBraam is working on a graphical pmbootstrap installer, where users would type in the password in a GUI before the installation, and then it would run pmbootstrap (or directly call internal pmbootstrap code) to do the installation with the preconfigured password (#1902 (closed))

Not good enough: yes | pmbootstrap install

When I'm testing installations myself, and also in the automated pmbootstrap qemu test, the yes command is used to set "y" as password for both the user and for the full disk encryption:

$ yes | pmbootstrap install --fde

But that's just a hack which spams the "password" into pmbootstrap all the time and does not allow to set separate passwords for the user and for FDE.

Problems

So why don't we just add a --password parameter and be done with it, like in !1919 (closed)? I don't think this is the right approach and that we should discuss it instead.

Tools that take security seriously, such as passwd, ssh or cryptsetup don't have a --password parameter either, and there is a reason for that: if we just pass it on the command line, basically every process running on the same system (no matter under which user it runs) can read the password from the command's arguments somewhere in proc, and it would also show up in tools like top. This isn't a good way to handle sensitive data like passwords so I would strongly discourage to implement it that way. Even if we only used it in test installations, just having the option available somewhat encourages using it, and I'm sure that users will use it at some point with real passwords not intended for testing, without knowing the consequences of having it exposed to parts of their systems where the passwords should not be. You may call that all theoretical, but this is bad practice.

Proposal from #1902 (comment 322271587):

[...] pmbootstrap install used passwd --stdin internally and then asked for a password with input(), this could also fix the extra time you need to fill in the password for FDE.

I like the idea, that this easily allows typing in the password up-front, even in the regular command line interface of pmbootstrap. But I don't think it's worth to trade that against the risk of exposing the user's password.

How can we make sure that it does not appear in pmbootstrap log, either in a stack trace when pmbootstrap runs into an exception, or while passing the password via stdin to passwd or cryptsetup?