Rethink PaymentClient/PaymentOrders

[0xNuggan]

Reconceptualization of the PaymentClient / PaymentProcessor relationship

After reviewing Issue #199 I think it's not really valid anymore, but I still feel the PaymentClient / PaymentProcessor could use some rethinking/simplification.

Pascal's intended design was to have a set of PaymentClients accumulating PaymentOrders, and then a PaymentProcessor pulling them on demand. The actual usage we are giving it is different, since we are basically calling processPaymentOrders() on each new creation of Orders. In essence, we are creating PaymentOrders defined by the Client locally and calling the Processor to handle them how it best can. This seems unnecessarily convoluted.

So I'd propose to remove the PaymentClient as defined class completely, and just have Logic Modules push payment orders to the processor directly.

The base PaymentProcessor interface would define a very general PaymentOrder struct (something like beneficiary, token, amount, bytes additionalData) and then each PaymentProcessor implementation would decode the bytes of additional data in the way necessary for their payout structure. Validation would happen at that point, and LogicModules could use ERC165 to make sure that the orchestrator is using a supported processor.

The final flow would look somewhat like this:

When a Logic Module wants to issue Payment Orders:
- It imports the IPaymentProcessor interface (or a more sepcific subclass of it). This contains the PaymentOrderStruct the Logic Module will use.
- It then creates PaymentOrders how it sees fit, and once ready, calls addPaymentOrder or addMultiplePaymentOrders on the PaymentProcessor. If the Module is holding the payout funds itself, it gives the processor pull approval. If not, the PaymentProcessor pulls the funds from the FundingManager.

From then on, all additional bookkeeping happens in the PaymentProcessor like we have it now.

I think this also simplifies the whole _ensureBalance interplay. As a side note, the MilestoneManager is the only module binding us to the old structure, and sice it is iceboxed if we decide to bring it back we could rethink the best format.

Here's a draft for the new PaymentOrder struct. Any feedback is very welcome!

stuct PaymentOrder{
    address beneficiary,    // Who will receive the payment
    uint amount,            // The amount of the payment 
    address payoutToken,    // In what token the amount will be paid out 
    bool pullFromModule,    // If the Funds should be pulled out of the calling module or from the FundingManager
    bytes additionalData    // Any additional data for subclasses to encode their parameters into.
}