Resilient tokens

Alright, the secret token RPC stuff has two issues:

1. Timing attacks: An attacker may figure out the secret by measuring the time it takes to do a request. Usual string comparisons will exit on the first mismatch (or even on mismatched length before that), so it is feasible to time this. The "better" the password candidate the more chars will be compared, the more time a request takes.This PR addresses this in the first two commits by doing a HMAC on the token (fixed length result) and the using a hopefully (mostly) constant-time array compare.
2. Brute-force (dict) attacks: An attacker may simply try to brute-force his way in. aria2 is damn fast processing those requests, which makes it to try out hundreds if not thousands of passwords per second. The usual way t limit this is to use a real KDF, such as PBKDF2, bcrypt or scrypt. The former seems to be good enough for our case, as we do not need any additional protection (e.g. memory-constraints scrypt introduces) since the secret is not that secret on the local system anyway in that an attacker with local access can just read it from the config/commandline/process memory dump anyway and a remote attacker will not see our derived key at any point. Hence the other two commits implement PBKDF2 and use that to compare tokens.