Review salt usage

[aaugustin]

Currently there are two uses of the SESAME_SALT setting, which likely have different characteristics.

From a quick analysis:

• The salt in sign and unsign is for preventing an arbitrary string signed somewhere else in the same app (i.e. with the same SECRET_KEY) to be accepted by sesame as a valid token. It doesn't need to be secret. It just needs to be unique within the app.
• The salt in create_token and parse_token is for making rainbow table attacks more difficult. (If such attacks are part of the threat model, probably you have bigger problems with django-sesame, but let's try to do things properly anyway.) Having the same salt for every token here makes no sens. Generating a random salt and storing it in the token would be better, but that would make tokens longer, while keeping them short is a design goal.

Ideas:

• Remove the suggestion to customize SESAME_SALT from the README.
• In the next tokens design, don't use a constant salt where that makes no sense.

[aaugustin]

Can't be fixed in tokens v1. Fixed in tokens v2 (#53).