Allow Empty Seat to Have a Proposal with Want, Exit

[katelynsills]

What is the Problem Being Solved?
#1389 solved the problem of needing to add a new seat, synchronously, from the contract side. However, it did so in a way that made this type of seat different from other seats in two related ways: there was no proposal, so there could never be any offer-safety enforced, and there was no exit rule specified in the proposal, so there could never be an exit afterDeadline.

However, neither of these restrictions is necessary. It's really only the escrowing of payments that is difficult, since the challenge is to do escrowing from the ZCF side through Zoe in a way compatible with getting a seat synchronously. But, we can add want and exit rules without trying to escrow anything and thus avoiding these difficulties.

Description of the Design

Allow calls to zcf.makeEmptySeatKit to pass in two arguments: want and exit which will be used to make a proposal. The exitObj is made like any other seat, meaning that the userSeat can be used to exit in exactly the same ways as other seats. If onDemand is specified as the exit rule, the seat can be exited on demand using the userSeat specifically. If afterDeadline is chosen, the seat will be exited after the deadline. If waived is chosen, the userSeat cannot exit. Of course, the zcfSeat can exit, but if the userSeat can be passed on to someone else or a different contract, it's still valuable to make the distinction in authority.

Security Considerations

I don't know whether this counts as a security consideration per se, but currently, under offer safety, giving nothing means getting nothing back fulfills the refund requirement. So specifying a want without any give is basically useless. It seems like it would be very useful to be able to make empty seats that have a want, but which give nothing, and which have offer safety fail if want is not fulfilled. I'm thinking in particular of ongoing contracts with a manager who is conducting many sales. For each of those sales, it'd be nice to make a new seat to represent the offer safety from the selling side, taking inventory from another, long-lasting seat. Perhaps rather than escrowing in the zcf.makeEmptySeatKit call, we should be doing a reallocate, such that give in the proposal for that seat makes sense and only has to match the reallocated amount, with no payments involved.

Test Plan
Add tests to exercise the userSeat methods to make sure they work the same as all other userSeats.

[Chris-Hibbert]

Maybe we want a way to specify that the give in the proposal is unsatisfiable? The idea is that offer safety would only be happy if the want was satisfied. I'm not sure what a good syntax would look like: { give: false } doesn't seem like it would work, but allowing some token to go in there that signals to isOfferSafe() that only want matters.