Capped global recipient set and global max float

The latest iteration of the PM candidate construction described in #15 involves the following:

- Os define their personal `maxFloat` values. An O will accept winning tickets with a cumulative value up to `maxFloat` before redeeming all the winning tickets on-chain
- Bs commit to a recipient set by submitting a Merkle root on-chain
- B's reserve should be equal to the `maxFloat` values of all of its committed Os
- If B exhausts its deposit, a committed O can draw on B's reserve up to `maxFloat`. Thus, a committed O is always guaranteed at least `maxFloat`. As long as O does not hold on to winning tickets past that value before redeeming, O does not risk losing money

The biggest downside of this construction is the requirement for B to commit to a recipient set - this means that whenever B wants to add a new recipient or remove a recipient it would need to submit an on-chain transaction.

An alternative to consider is to remove recipient set commitments and instead to allow B to work with all members of a capped O set. There would also be a globally defined `maxFloat` value. B's required reserve would then be calculated as `size of O set * maxFloat`.

However, while B would not need to update its recipient set, it would still have to increase its reserve whenever the size of the O set increases. To avoid this, B can set its reserve as `max size of O set * maxFloat`. The downside here is that B's reserve requirement might not reflect the actual number of Os if the size of the O set is less than the max size i.e. B is basically over collateralized. Furthermore, this only works if the max size of the O set is known i.e. it would only work if there was a fixed # of Os on the network

The issue names no repository files, tests, or entry points. Start by reviewing the PM candidate construction in #15 and compare the committed recipient-set design with the capped O-set and global maxFloat alternative. Done would require a decided construction and its reserve and recipient-set constraints.

Written by the indexing model from the issue text.