Allow registration of claims on behalf of someone else

[reednaa]

Currently, registrations are only allowed for the sender or the signer of a permit2 approval. This works in a gasless context but if The Compact is used as an intermediary between protocols this doesn't work or requires the user to sign an additional message.

The PR proposes a solution, allow someone to provide the specifics of a deposit and then register a claim for the amount deposited. This ensures that nobody can register arbitrary claims (since the maximum claim is the amount deposits) and allows TheCompact to act as a single integration surface for a protocol: i.e, it can be used directly from the user wallet or as an intermediary as part of a series of other calls.

This PR is not finalized. Only simple claims and batch claims (with witnesses) are implemented. Additionally, logic is not optimized nor tested.

[reednaa]

After optimising the lowest hanging fruits, the current margin is -1087 bytes.

After thinking more abotu it, I don't believe that someone else should be able to deposit multichain claims on behalf of someone else. It seems silly that some of the components of the multichain claim may have been deposited while others havn't.
This may also be an excuse I have told myself to not add additional interfaces which would increase the code size even further.

[0age]

agreed that registering multichain compact types on behalf of someone else doesn't make a whole lot of sense — the third party would just register each compact individually on a per-chain basis, though of course the claim conditions could still be linked if needed

the most significant modification here is going to be extending the permit2 deposit methods to support depositFor + registerFor

[reednaa]

the most significant modification here is going to be extending the permit2 deposit methods to support depositFor + registerFor

I am unsure what these functions will achieve. Currently, the existing interfaces allows you to collect tokens and optionally register a claim for someone through permit2. Indeed, the deposit and registration is specifically for the signer, however, I can't conceptualise in what situation someone would deposit for someone else specifically gaslessly.

A registorFor function would just work like preemtive claim and would only act to execute portions of the claim logic earlier.

The specific purpose of the interfaces in this PR, is to allow a UI interface / protocol / intermediate contract to independently collect tokens and then deposit and register a claim on behalf of someone else.

Example 1: Composability of intent protocols. Imagine that protocol A wanted to handoff assets to Protocol B and Protocol B used TheCompact as its sole deposit interface. In such a world, the alternative to the proposed interfaces is to deploy a smart account for the user and call TheCompact's deposit interface through the smart account intermediate.

Example 2: Legacy UI interfaces with a aggregation / router contract that collect tokens and then deploy them to various protocols. If a protocol wanted to support these, it would have to either: 1. Implement a secondary deposit system. 2. Deploy a smart account for every user.