Add context parameter and domain separation to match FIPS 205

[jonmon6691]

FIP205 now requires the message to be pre-pended with some additional information before being signed or verified. This PR is intended to implement those changes.

The functions should now sign/verify the message as altered: M' = 0x0 || ctx.len() as u8 || ctx || M Where

• 0x0 is the domain separator indicating this is a pure signing function as opposed to a pre-hash signing function.
• ctx.len() as u8 is the length of the context limited to 8 bits
• ctx is the context
• M is the message to be signed

Updating comments to match released FIPS 205 is in scope for this PR

Adding pre-hash versions of the sign and verify functions are out of scope for this PR

[jonmon6691]

Partially addresses #1

[jonmon6691]

Trivially prepending bytes onto the message to be hashed will require allocating and copying memory which goes against the "label on the box". Alternatively, the functions consuming M could be modified to accept the prefix as arguments. I haven't investigated if this is feasible yet.

[jonmon6691]

Okay so the new M' change to include a domain separator byte, context string, and oid string is implemented with https://github.com/integritychain/fips205/pull/2/commits/795ac5bba6450848aaa637b4033312d86d52ae45 and the round trip tests all pass. But I'm still working on setting up to test with the vectors on ACVP. These were posted before the standard release so I'm not entirely sure they should pass. SLH-DSA-keyGen-FIPS205, SLH-DSA-sigGen-FIPS205, SLH-DSA-sigVer-FIPS205

As for prepending the message, I used a not-very-idiomatic approach of putting all the new message parts into the type signatures of h_msg and prf_msg. This keeps everything on the stack and plays nice with the borrow checker, but opens the doors to possibility of expressing invalid states.

I played around with trying to come up with a system of Message types like PureMessage and PreHashMessage with trait impl's to get their contents that the underlying hashers could use. But I was running into a lot of issues handling the generics and lifetimes correctly so I decided to back off. If that's your preferred approach @eschorn1 , let me know and I'll give it another shot but I'll need a little help to wrap my head around it.

[jonmon6691]

As mentioned in #3, I can't find any official test vectors to update all the known answer tests in this crate that are now failing (as they should). So I think this PR is blocked until there are trustworthy tests that can be run.

I'm considering expanding the scope of the PR to include PreHash variants of the signature and verification functions in the mean time since I think besides tests, this is already fulfilling what I originally set out to do.