ScryptPasswordHasher cannot verify hashes with derived key lengths greater than 64 bytes

[Dominic Roy]

ScryptPasswordHasher currently hardcodes dklen=64 when calling
hashlib.scrypt().

As a result, Django cannot verify otherwise valid scrypt password hashes
generated by another implementation when that implementation uses a larger
derived key length.

This came up while working on password hash compatibility in authentik
(​https://goauthentik.io), where imported scrypt hashes may come from systems
using different dklen values.

For example, using the same password, salt, N, r, and p values:

scrypt$16384$django-scrypt-example$8$1$D5reUgzHkb7jsUr+tu+tLDdM7Zx9ogzquC0AJYM1U6irspdgjDMDL7GforSHakP8eTjb3aDsBw+VLv+odzzPpA==
scrypt$16384$django-scrypt-example$8$1$D5reUgzHkb7jsUr+tu+tLDdM7Zx9ogzquC0AJYM1U6irspdgjDMDL7GforSHakP8eTjb3aDsBw+VLv+odzzPpDHtdiQLBYg3cABNaUmj/LOy7C0gbqe9Tt3TA/GAuuaql9RhoeGh57L7aDdxGhddkCbrwxLVvzJxa6YRW1XqdCs=

The first uses dklen=64 and can be verified by Django. The second uses
dklen=128 and currently cannot, even though all other scrypt parameters are
the same.

Django should probably keep 64 bytes as the minimum accepted derived key
length rather than accepting arbitrary shorter hashes. However, hashes with a
larger dklen, for example 128 bytes, currently fail verification because
verify() always regenerates a 64-byte result.

The derived key length can be recovered from the length of the Base64-decoded
digest. verify() could use that value when it is at least 64, while Django
continues generating new hashes with dklen=64.

If appropriate under Django's backport policy, it would also be useful to
include this in Django 5.2 LTS.

I'm happy to submit a patch with tests if this approach is accepted.