GH-554: Give PaymentAdjuster its intelligence

[bertllll]

Straight continuation of #GH-672, by which this is blocked.

Might be continued by #GH-699.

The previous card introduced a dull PaymentAdjuster, now make it smart.

The core of PaymentAdjuster should be a system of various criteria applied to the set of qualified but excessive payments. The criteria will determine which account will take a priority or at least which payment should be resolved with the biggest fraction of it compared to the others maybe paid by some smaller portion of the actual debt, another possibility is to drop some marginal ordered payments completely, leaving the taken up means for the other accounts and therefore solving the problem of insufficient balance.

There are many ways which can lead to some sort of solution strategy. That's the crucial part of the preparation for this card as a good one needs to be chosen also with such regards as whether that has got good chances for some future enhancement, that is extending the functionality by applying more criteria.

The first question to solve might concern:
a) we could apply some logic that will proportionally reduce the full size of the debts and so every account will get at least some portion paid
b) we also can threat the debts as unmodifiable in their size and so we would have to chose accounts whose debt sum will get the closest to the balance that we can operate with.

Here are some examples of attributes by using which we could calculate if the given account is more or less important to take more interest in the pay-off:

a) direct math applied on the whole set:

• set that is wide as possible to touch the highest number of accounts
• set that includes accounts with the biggest debts
  ...

b) based on additional metadata:
*notice that all these points assume we would ask the Neighborhood for some information we need to know

• if the Neighbor the account belongs to is actually our immediate Neighbor
• number of Nodes connected to the Neighbor (more is better)
• using this Neighbor's payment thresholds (most complicated - because so far we have never tried sharing this data with other Nodes and we don't know what the consequences of that would be)

Suggestion: exclude the connection to Neighborhood for this moment and add just some elementary criteria, that should help with reviewing etc. because it can be considered an isolated extra complexity. Do that in a separate card rather.