@epriestley I'm going to rearchitecture this so that admins can create concrete blueprints in the UI based on a "Blueprint Implementation" (which will be the list of classes actually implemented). This will allow admins to create multiple concrete blueprints from an implementation and thus restrict differents sets of people to doing different things (so I can say that people in the "QA" project have access to one concrete blueprint, it's resources and it's leases, and people in the "Devs" project have access to a different blueprint and it's resources & leases).

I'll unify the policies so that view and edit carry from the blueprint to the resources and leases, imply that CAN_EDIT gives you the ability to lease and resource (and remove the explicit lease and resource policies). If people require the ability to distinguish editing and resourcing/leasing later we can always add the extra policy rules, but we can't do the reverse.

I've updated the revision title and description to reflect the new purpose of this diff.

I think I've got all correct call sites (by testing the functionality through bin/drydock and the UI), but I can't be sure. In particular, I don't like the fact that half of the code now uses a variable called $blueprint and means "the implementation", and half the code uses $blueprint and means "an instance". The only way to fix this up is to probably manually go through all of the code and change the variable from $blueprint to $implementation where appropriate.