Extensible permissions system

After cleaning up the plugin patch (Issue 847), I realized that there was no existing way to implement permissions for plugins. The PP permission system used hard-coded permissions stored in the database as columns in the project_users table. That's okay for built-in stuff, but not for plugins and not if we start adding more permissions to the built-in stuff...the table would end up having dozens of columns, one for each permission.

The past two days I noodled around with the code and came up with the patch included here.

Modeled after the plugin system, I created an extensible permissions system grounded in the PermissionManager class. Permissions are stored in two database tables:
1) The "permissions" table, which contains a list of possible permissions organized by source (i.e., module or plugin) and permission name (i.e., 'manage').
2) The "project_user_permissions" table which contains a (user_id,project_id,permission_id) tuple if the permission is granted, and no corresponding tuple if the permission is denied.

I imagine I coded some stuff stupidly, and perhaps redundantly. This code needs major review, and possibly a complete re-design. This is meant to be a proof-of-concept, much like the plugin system patch.

I also imagine I missed some places in the code that need to be changed to use the new system. I got a lot of them, but there are probably some bugs lurking around in the code.

BIG FAT WARNING: you'll have to user /public/upgrade/migrate_permissions.php to migrate permissions to the new tables. The script only lets you upgrade; I didn't ever write the downgrade portion. As such USE AT YOUR OWN RISK. It will modify your database and going back will be a painful manual process.