Add AbstractSplitter

[Amxx]

This is a prototype for a PaymentSplitter contract that supports dynamic shares.

Unlike the version we had in 4.x, this version allows minting/burning/transferring shares. The downside of this approach is that it only supports one token. If configured to handle (and split) ETH, then any ERC20 token sent to it would be locked*. Similarly, if it is configured to hangle (and split) USDC, then any USDT/Dai/... would be locked*.

* unless a recovery method is implemented.

[arr00]

If the balance or allocation exceeds type(int256).max, it could result in reverts for that account. I don't think it's a real issue though, because the user can always transfer shares over the max out, and then proceed as normally. It may be worth documenting in case a dev would restrict transferring while also dealing with massive numbers.

[Amxx]

because the user can always transfer shares over the max out, and then proceed as normally

If the computation of _allocation overflows, because _balance() + _totalReleased overflow, then:

• no one can release
• no one can transfer shares, because that includes a computation of _allocation to estimate the virtual shares to add/remove.
• moving shares would not fix that anyway.

So this would basically kill the contract. Note that the v4 splitter had a similar issue, but with type(uint256).max instead of type(int256).max ... (the difference between the two is just a factor of 2)

[Amxx]

Just noticed: we need to test :

• adding shares to an account that already have some share
• partially burn the shares