Add salt to public key to mitigate rainbow table attacks

Previously miniLock used a fixed salt for scrypt, which means that only one rainbow table would need to be constructed to determine all passphrases.

I have changed this so that a random salt (16 bytes) is generated each time the public key is derived. You would now have to generate a rainbow table for that salt to try and determine the original passphrase.

The salt is appended to the public key in the miniLockID (which adds 16 bytes of length). When someone uses your miniLockID to encrypt a file, it encrypts according to the public key and appends the salt to the encrypted file. That way, when you go to decrypt the file, you can re-create the private key based on your passphrase and the appended salt (thus decrypting the fileKey).

One noticeable difference is that the miniLockID changes every time you load the app, even for the same passphrase. However, this does not prevent you from decrypting files sent to you using an older miniLockID, since the salt is included in the encrypted file. Additionally, someone can still encrypt a file and send it to you using a previous miniLockID. As long as the user knows their passphrase, they can decrypt a message sent to any of their generated miniLockIDs.