Adds abstract parent class to permissions

[kaw2k]

Approach

Have a single class that all permissions inherit from. This class calls toString on its sub-class so all permissions have the same structure { type: string, payload: string }. This lets us serialize them all uniformly. This adds a bit of complexity, I'll call that out via inline comments.

Motivation

The previous implementation of permissions required us to break out each permission into its own section due to serialization. For example, in connect we would need to have each permission separated:

interface Args {
	network?: Network;
	fungibleAssetPermissions?: FungibleAssetPermission[];
	gasPermission?: GasPermission;
	nftCollectionPermissions?: NFTCollectionPermission[];
	nftPermissions?: NFTPermission[];
} 

This PR adds a base class that all permissions inherit allowing us to have homogenous arrays for use in serialization. It is easier to allow for each approach now.

interface Args {
	network?: Network;
	permissions: MovePermission[]
} 

Comparison of approaches

There are pros and cons for each approach, here is what I have observed:

Homogenous Permissions:

Pros:

• Requesting permissions has less keys to worry about, making that DX a little easier.
  Cons:
• The implementation is a bit messier, needing helper types and more plumbing.
• Returning a homogenous array of permissions back to the user requires them to check the class instance of each permission, which is cumbersome.

Heterogeneous Permissions:

Pros:

• Simpler implementation in the TS SDK.
• Ingesting permissions is easier as we don't need to type check
  Cons:
• More cumbersome to request permissions. For example, imagine a wallet that allows users to revoke partial permissions for a dapp. The UI would need separate arrays for each permission type, vs a single array to hold all selected permissions.

With a base class, we can offer both experiences (homogenous and heterogenous) and let individual wallets decide the DX they want to provide.

Open to critiques, enhancements, or just scrapping this.

[kaw2k]

So what is going on here:

Since the overall approach is to convert all permissions into a flat string, we need to first convert all inner properties to strings. This helper type (ToPayload) ensures we have type safety during that conversion.

Each permission has _PermissionProperties which is what is stored within the class as well as _PermissionPayload which is used in (de)serialization.

Fungible asset permissions are bit unique. I wanted to allow the constructor to accept amounts as bigint OR number for ease of consumption. The class converts that to a bigint to standardize it.

[kaw2k]

Overloading from allows us to ingest the deserialized string/json object where every property is a string OR the proper types as if the dapp is creating a permission. Again, this is probably overcomplicated.

[kaw2k]

Example test case.

[networkdm]

Hi there, I'm working on running these test cases for the sub-accounts functionality. I understand that the sub-accounts branch on the https://github.com/aptos-labs/aptos-core repository should be compatible, but I'm noticing some newer branches related to permissioned delegation.

Could you advise on the most suitable branch to use for my testing purposes? I'd be happy to consider the newer branches if they provide any advantages for running these tests, or if there are any known issues with using the sub-accounts branch.

[kaw2k]

The branch I am currently based on for aptos-core is sub-accounts-gas. I have not yet pushed the latest commits ts-sdk branch for that base, I hope to do that this afternoon. The ts-sdk branch that will have those commits is sub-accounts-gas-permissions.