feat: AuthorizationLock

[tracy-codes]

This Pull Request adds the following:

1. AuthorizationLock which allows an authority to pre-authorize a number of tokens given its mint and set an expiry. This will ensure the SWIG doesn't overspend in the case of pre-authorization a transaction before settlement allowing for delayed settlment from SWIGs.
2. ManageAuthorizationLock permission required to add AuthorizationLocks
3. AddActionsToRoleV1 and RemoveActionsFromRoleV1 new instructions to allow for in-place addition/removal of Actions on a given Role.
4. Fixes a couple of remaining bugs found with the boundary calculations in other functions like get_all_actions

Here's how things are set up:

• Only an authority with ManageAuthorizationLock or All permissions can add/remove AuthorizationLock
• An AuthorizationLock can technically be added to any role/authority, but it applies to the entire Swig
• A SWIG can have multiple AuthorizationLock s, they are additive when they are added for the same asset. For example, if you have 3 AuthorizationLock s that have different expirations sometime in the future for USDC of 100 USDC each, then they will combine to be a 300 USDC AuthorizationLock check
• On SignV1 , if it's a SOL or SPL transfer, no matter if the role has All or not, if the swig has at least 1 AuthorizationLock then the before/after balances are checked against all AuthorizationLock s for the asset(s) being transferred.
• An AuthorizationLock can only be removed in 2 ways; it expires or it is manually removed
• Only the Role id that added the AuthorizationLock can manually remove it before its expiry.
• Once an AuthorizationLock is expired, it is automatically cleaned up from the SWIG on the next SignV1 call or it can be manually removed by the authority/role that added it.
• A SWIG with no AuthorizationLock s on it has 0 CU overhead in comparison to before this functionality
• A SWIG with AuthorizationLock s is benched at roughly +700 CUs overhead required

[tracy-codes]

After some feedback, we're going to change this implementation a bit to not use Actions for AuthorizationLock and an AuthorizationLock needs to respect it's acting role's token limits when it's being added.

[tracy-codes]

Superseded by #35