Rudimentry policy enforcement.

@jurisv This is a rough implementation of the discussion we were having last week about policy enforcement and securing methods that are exposed at the service layer.

It's ready for discussion but certainly not merging.

The basic idea is the ability to put strings in your methods that match the pattern
{classPrefix}:{key}:{value}

Before executing the method, we parse it gather this metadata and then pass it to a Policy class. The policy Class is configured by passing in PolicyClass (will fix case to be policyClass). This PolicyClass implements an isAccepted method and is passed the metadata and the request object (so it can read things like session variables).

This information could certainly be built and cached when we generate the api and re-used.

It solves the problem of execution of methods that should not return any data but it does not solve the problem of having those methods in the API stub itself. Problem is it's not just as simple as saying x,y,z methods belong to this group and a,b,c methods belong to this other group. Execution can be very contextual, ie did the user already complete this step or the next one, etc

Thoughts?