Re-architect rpc-cap

[rekmarks]

At the moment, rpc-cap consists of:

• RPC method implementations for requesting and retrieving ZCAP-LD-like permission objects
• A CapabilitiesController (in the vein of @metamask/controllers v1) that stores and and manages said permission objects
• A set of json-rpc-engine middleware that enforce the permissions represented by said permission objects

In other words, rpc-cap is three distinct things in one, confused package. Moreover, it's difficult to integrate with the rest of our stack, as evidenced by the ~700-line extension permissions controller, which is more or less a wrapper for the various components of rpc-cap.

To properly modularize rpc-cap and make it easier to work with, we (minimally) need to:

• [x] Extract the CapabilitiesController into a separate module (https://github.com/MetaMask/snaps-skunkworks/pull/28)
  • [x] Finish base implementation
  • [x] Finish types
  • [x] Finish tests
• ~Integrate new permission system into extension~ (Tracked elsewhere)
  • Replace the extension permission controller with the v2 permission controller
  • Replace the extension permission metadata functionality with the new metadata controller
• [x] Consider whether to stick with ZCAP-LD, or switch to a simpler format
  • We're sticking with it. I claim that we can obtain many of the properties of an object capability system in production, and the alternatives I came up with were not significantly simpler.
  • Old notes:
  • Our use of ZCAP-LD is mostly aspirational, because rpc-cap is ultimately an access control list (ACL), and we do not have the means to implement object capabilities in any real sense.
  • However, the format of our permissions objects is mostly abstracted away from us and our consumers, and it might make a future transition to ocaps easier.
• [x] Extract the middleware into a separate module
• [x] Extract the RPC method implementations into a separate module
  • This includes extracting the requestPermissionsMiddleware into the implementation of wallet_requestPermissions
• [x] Extract pending permission request functionality into ApprovalController and RPC method implementation
  • [x] This requires migrating the ApprovalController to BaseControllerV2. See: https://github.com/MetaMask/controllers/pull/555
• [x] Extract permission metadata functionality into a separate controller (https://github.com/MetaMask/snaps-skunkworks/pull/61)
• [x] Make a decision about the extension permissions log

[rekmarks]

Closed by https://github.com/MetaMask/snaps-skunkworks/pull/132