Add escrow payment and allocate to recipient ContractSupport Helper

[katelynsills]

Closes #992
Closes #1010
Closes #1012
Closes #1013

[Chris-Hibbert]

just a correction on an internal comment. otherwise, LGTM

[erights]

Please revert that last change. It isn't quite what I have in mind, and the previous state is a better starting point. I also am not certain the refactoring I have in mind works.

Since the code as currently written is correct and follows the style of other approved code, I'm gonna say LGTM without this last commit. Approved to merge.

Then, when we have the time, let's look at refactorings of this pattern.

[DavidBruant]

If i recall correctly, the opera ticket contract and autoswap were users of the previous pattern and should benefit from the new helper
I think it'd make sense to change them so the pattern of self-invitation disappears from contract codes

I don't have an opinion on whether this work should be done as part of this PR or a folow-up one

[katelynsills]

If i recall correctly, the opera ticket contract and autoswap were users of the previous pattern and should benefit from the new helper
I think it'd make sense to change them so the pattern of self-invitation disappears from contract codes

I don't have an opinion on whether this work should be done as part of this PR or a folow-up one

Good idea. I like including their changes in this PR.

[katelynsills]

Meta note: since this is adding a helper that hackathon participants probably need ASAP, and is not changing the Zoe API, I'm going to keep the base on this as master

[katelynsills]

@erights, I had to make two bug fixes in the latest commit:

Offer Safety Check with Sparse Keywords

#1012
If not all 'give' keywords are in the allocation, that should be ok, but refundOk should be false. Right now it throws:

updateAmounts with Sparse Keywords

#1013
We shouldn't be overwriting the allocations if the allocations might be partial, using sparse keywords

[Chris-Hibbert]

I'm fine with this change.

[erights]

LGTM