Add optional FAKTORY_WEBUI_PASSWORD with argon2id, bcrypt, scrypt, and PBKDF2 support

[f3ndot]

Closes #510

New functionality:

1. FAKTORY_WEBUI_PASSWORD can be specified. If set, it will configure the Web UI with that password otherwise will fallback to FAKTORY_PASSWORD value. This is the existing behaviour for the undocumented TOML config [web] subsystem's password element.
2. If the configured Web UI password string conforms to the Password Hashing Competition (PHC)'s format and a supported hashing algorithm is identified, the HTTP Basic Auth password will be hashed and compared accordingly. Otherwise plaintext is assumed and is string compared normally.

Rationale:

1. The PHC format is a looser version of the well known Binary Modular Crypt Format (BMCF) that we've seen in /etc/shadow after all these years. It's considered the de facto standard for representing password hashes in a non-standardized world of password hashing. It's what's used by Argon2 and the likes. Popular hashing libraries like Python's passlib use it and should come as no surprise to developers using Faktory.
2. OWASP's current guidance for password hashing algorithms are argon2id, bcrypt, scrypt, and PBKDF2. These are considered still secure algos (when parameters properly set) and seem like a good set to support.
3. The algos are all available in the officially supported golang.org/x/crypto module, so we can trust the implementations are cryptographically correct.

Interface:

There is a new password module with func Verify(candidate string, configured string) (bool, error). This is what will allow detection of password hashing algos and match accordingly (or fallback to plaintext).

[mperham]

Looks like some CI failures?

[mperham]

Code looks great and nice PR writeup. Well done.

[f3ndot]

@mperham FYI looks like this module isn't used anymore and tidy dropped it.

[f3ndot]

@mperham should be good for another CI run and ready for merge at your convenience. Needed a go mod tidy to get the deps right for fresh compilation

[mperham]

I'm not a fan of creating a new password package just for this code. What do you think about rehoming it in util?

[f3ndot]

Makes sense to me. Once I did that, I had a random memory usage test fail in util as a result. I suspect one of the password algo tests is memory heavy? I'm going to have to poke around first. Will also push an experimental commit that parses the configured string once during boot, not every time during comparison