Signing key separator

Nobody has claimed this yet.

Hi! Thanks a lot for your work on this crate. I stumbled upon it in time while solving a cookie signing/encryption problem.

I would like to know if I understand correctly the idea/necessity of having a separator in the cookie name=value pair -- accordingly, two 3 questions:

(I also read a comment on reddit (https://www.reddit.com/r/rust/comments/1bb7vtm/comment/kua9fgd/) about this)

1) The separator is necessary because otherwise manipulating the name=value pair (the split location) can potentially lead to parsing a different valid name=value pair that is meaningful to our application. A=BC instead of AB=C. Unlikely, but still possible.

2) The separator itself must be specific, so that in case of manipulation of the split location, it does not become part of the name or value that is meaningful to our application. Therefore, one of the options is the byte sequence 0xFF (as mentoined on reddit). Why? Because it is an invalid byte sequence for representing a string in UTF-8 encoding? Therefore.. at any stage of processing this value as Rust String (which is either a cookie name or a value) that includes this byte sequence, we will get an error/panic (because Rust strings cannot be invalid UTF-8) the desired error/panic that protects us..?

3) Then why is the separator null byte, that is valid for UTF-8 and Rust String:
```
const SEPARATOR: u8 = 0;
```
but not 255 (0xFF):
```
const SEPARATOR: u8 = 255;
```

(At the same time, the specified manipulations (with or without separator), of course, do not change the HMAC tag, therefore the signature can potentially be successfully verified)

Locate the `const SEPARATOR: u8 = 0` definition in the crate and trace how it is used during cookie signing and parsing. Document the separator's purpose, why the null byte is chosen instead of 0xFF, and how the relevant manipulation concern is handled.

Written by the indexing model from the issue text.