Added a cryptographic utility class

Generates strings, integers, and bytes using the best available system
CSPRNG. If no suitable source is found dependent functions return
false. Especially useful for creating good passwords.

Large portions are based on the code found here:
https://github.com/defuse/php-passgen/blob/master/PasswordGenerator.php
Added package links back to the package editor

Instead of accessing hidden packages through their easily guessable or
enumerable database ID, each package is now assigned a 16 character
case-insensitive (database dependent) alpha-numeric password. This
password is generated using a CSPRNG from the new Crypto utility class.

According to GRC.com the search space size for package passwords will
be about 8.19 * 10^24 and should hold up for, at max, about 26
centuries given one hundred trillion guesses per second. Assuming a
more practical one thousand guesses/sec we're looking at 2.6 trillion
centuries.

Package passwords can be reset at any time and the previous password
will no longer work. Passwords will not function on disabled packages.

Internally the package password concept is referred to as a "hash"
because during development I planned on using two concatenated CRC32
hex hashes. While the search size was ok (i.e.: not too good, not too
bad), it seemed like an unnecessary shortcut. Implementing a proper,
more secure, and better seeded method was well worth it. Speed most
certainly is not an issue as the code only runs in the package editor.

Despite being a password and "secret" it is not being hashed in the
database. Hashing the password is useless if you're going to be using
the link publicly to provide a shortcut to the package. It also
prevents the admin from needing to remember the password which would
probably be stored somewhere in plain text anyway (like the notes
section on the ACP home page). The only true disadvantage is if an
attacker has access to an old copy of your db (not live) he can
sign up for any hidden package he wants assuming they haven't changed.
Any personal info on the users table is more valuable than that. Unless
of course you have a hidden package that offers shell access enabled by
default. That can be avoided easily by not giving shell access by
default on any package (it's a bad idea), or at the very least, forcing
that package to be subject to admin validation. That won't prevent
account creation but it will prevent them from logging in. If you're
truly concerned you should be completely disabling any packages that
people should not be signing up for. After a client has signed up for a
hidden package immediately disable it or reset the pass as there's
nothing preventing them from sharing it.

Single-use package passwords are an interesting idea but probably
overlap with a promotions/discount code implementation. As described
above, single-use package passwords are completely possible it's just
not automated. You could make a cron script to update the passwords
every so often.

If there's a huge outcry I'll hash the damn package passwords but it's
looking like the convenience of plain text is worth it here.