Multiple issues with k3/k4 public/secret vectors

[bannable]

These vectors fail to provide a PASERK Type input and thus are exercising only input correctness checks on the underlying key class, and not testing the Type or Operation:

• k3.public-fail-1
• k4.public-fail-1
• k3.secret-fail-1
• k3.secret-fail-2
• k4.secret-fail-1
• k4.secret-fail-2

Additionally, the PASERK provided in k3.local-fail-1 and k4.local-fail-1 are not validly encoded RFC 4648 Base64, and so fail to exercise the length constraint that the comment suggests they should. This is the same sort of problem as #18, but instead of mutating the encoded Base64 the vectors have simply dropped the first byte of the encoded output. Instead of dropping a byte from the encoded output, you should drop the byte from the raw key and then encode the result.

Both k3.public and k4.public are missing short input test vectors.

Finally, there are no vectors that test for keys where the private component is unrelated to the public component.

With the k4.secret vectors, no test covers the case of a libsodium (r | s) keypair where s is not related to r. For example, this scalar value:

5f445f215af4331f567339bc83308b16694f6b8e70e1d0e24ce192e91e02831

should have the associated r of:

0bd3c6270088ea35eafdd38edfb7bfd107107df533b82903b39576ccb6c8c48e0

but there is no test for an input (r | s) keypair such as:

5f445f215af4331f567339bc83308b16694f6b8e70e1d0e24ce192e91e0283100000000000000000000000000000000000000000000000000000000000000000

I've created some V3 inputs that test for different ways the EC keys may be invalid under NIST SP 800-56A criteria:

• here OpenSSL may load this input, but it results in dG != Q
• here the input is of the incorrect order: it's a p256 not a p384 key
• here d is outside the curve interval