TACo Subscriptions

[cygnusv]

Initial design from @vzotova and yours truly:

• Subscription is a per-adopter contract that holds credit units (or simply credits).
• Subscription has an expiration date, but there's special periods after this date. See Cohort End of Service: Yellow and Red periods #262
• Authorized contracts (like Coordinator and AllowList contracts) can "spend" credits from a Subscription.
• For the moment, Subscription contracts will be individual, with logic implemented in a case-by-case basis, but with the goal of generalizing a common factory contract down the road. The latter makes sense for the permissionless phase. For the moment, lets allow ourselves to experiment and offer what's best for each adopter.
• For the same reason as above, first subscription contracts will be upgradeable.
• Potentially, Allow other currencies to pay for TACo fees #263
• Subscription contract will specify rules for topping up (see Top-up ritual to extend duration #93 )
• Once service is charged (e.g., a ritual is initiated, an encryptor authoriation is realized, etc), fees may be sent directly to TG multisig. Alternatively, they can remain in the contract, but will be withdrawable by TG multisig.
• For the moment, let's handle refunds manually (i.e., involving the TG on a per-case basis).
• TG will be capable of "topping up" a Subscription contract with more credits if necessary (e.g., grants, testing, internal use, etc).
• Subscriptions can be seen as an evolution of the BetaProgramInitiator contract, which was only designed for ritual initiation.

Changes required in Coordinator and other contracts:

• Coordinator shouldn't implement IEncryptionAuthorizer logic #195
• Coordinator doesn't handle fees directly anymore, just spends subscription credits.

[vzotova]

Some additions (see #265):

• Subscription, or basically IFeeModel, is responsible for allowing or not initiateRitual.
• Each fee model can use any currency and any rules regarding it
• Each fee model must be authorized in Coordinator