Support Apache Shiro and slapd Argon2 hash encodings

https://shiro.apache.org/cryptography-features.html uses Argon2id hashes, but encodes them subtly differently. Test vectors from CMIYC 2024 cracks:

$shiro2$argon2id$v=19$t=1,m=65536,p=4$z0RJt6Ddj3RwojqdC7ldPw$GlQ2aON2k6zNEIAVUgxounobxAFbpPXh8dQkPFUvexM
$shiro2$argon2id$v=19$t=1,m=65536,p=4$2IbMDqCmh/5RI5sVZzMdUw$fwqL7fb+UY2MDL2r4QXGGExJwK05yxolYjnY1xlFje0

were after a sed crackable by our argon2-opencl like this:

$argon2id$v=19$m=65536,t=1,p=4$z0RJt6Ddj3RwojqdC7ldPw$GlQ2aON2k6zNEIAVUgxounobxAFbpPXh8dQkPFUvexM:Aditya@2011
$argon2id$v=19$m=65536,t=1,p=4$2IbMDqCmh/5RI5sVZzMdUw$fwqL7fb+UY2MDL2r4QXGGExJwK05yxolYjnY1xlFje0:Aarush@01

We could want to add a split() or prepare() to remove the $shiro2 and put m and t in the canonical order. Alternatively, for the latter we could patch upstream Argon2 code not to insist on the order, but then there would be more than one representation of the same hash in john.pot, which is undesirable.

Start by tracing the Argon2 format handling and the argon2-opencl integration referenced in the issue. Compare the two Shiro vectors with the canonical forms shown, then verify that both encodings are recognized and normalized consistently without changing the stored hash representation.