Alternative sign() payment design

[volovyks]

Currently, we have the #[payable] sign() function with a dynamic pricing model.
Downsides:

• Unpredictable price, users do not know the exact price of a signature.
• Each change of the minimum signature price is a breaking change.

Alternative design:

• sign() always requires 1 yN of deposit
• users must call fund() and attach a deposit of their choice
• Users are charged for each successful sign() request from their contract balance

The alternative design allows both static and dynamic sign() request price models. I'm leaning toward a static one.

[think-in-universe]

I created a relevant issue in #814, and I do prefer the above model over the existing one.

I just want to point out that it's important to consider the case that the user is a contract. For the fund function, I would suggest it takes one receiver parameter, so that one can fund others when necessary.