Add PodAdmin gateway - expose admin fns and veto

[thomas-waite]

Summary

Introduces a PodAdminGateway contract, which is set as the PodAdmin address for all deployed Orca pods.

It is introduced for three reasons:

• Allow a given pod to have it's admin functionality exposed to several TribeRoles
• Enable hierarchy amongst pods. There is a concept of a "specific admin role", the role for which is calculated deterministically. This allows higher ranking pods to be given a higher a special role to administer lower ranking pods
• Enable pod proposals to be vetoed by higher ranking pods

The goal is for the pods to have the following TribeRoles with the following admin priviledges :

• addMember(): GOVERNOR, POD_ADMIN and specific pod admins granted this granular role
• removeMember(): GOVERNOR, POD_ADMIN, GUARDIAN and specific pod admins granted this granular role
• veto(): GOVERNOR, POD_VETO_ADMIN, GUARDIAN and specific pod admins granted this role

[Joeysantoro]

I think a much more scalable architecture would be to hash the podId with some salt like "ORCA_POD" and have that role be the "specific pod admin". We'd only need at most one of these roles per pod. Instead of giving ROLE_ADMIN the control over this, perhaps a better role would be "POD_ADMIN" which specifically can do all of these things. The POD_ADMIN should also be able to grant these role specific admins. So then we have the following admin priviledges for all pods:

AddMember(): GOVERNOR and POD_ADMIN and "specific pod admin"
RemoveMember(): above plus "GUARDIAN"

[thomas-waite]

I think a much more scalable architecture would be to hash the podId with some salt like "ORCA_POD" and have that role be the "specific pod admin". We'd only need at most one of these roles per pod. Instead of giving ROLE_ADMIN the control over this, perhaps a better role would be "POD_ADMIN" which specifically can do all of these things. The POD_ADMIN should also be able to grant these role specific admins. So then we have the following admin priviledges for all pods:

AddMember(): GOVERNOR and POD_ADMIN and "specific pod admin" RemoveMember(): above plus "GUARDIAN"

This makes sense and I like it, it's more scaleable as you say. Implementing