fixed transfer quickstart

[phoenixy1]

So, the problem is that the transfer quickstart endpoints were based on the Payment Initiation quickstart endpoints -- all the button in the quickstart does is get details of the completed payment.

However, this was the wrong paradigm to use, because in payment initiation, the payment is interactive and takes place during link, whereas for Transfer (unless you're using transfer UI), the payment requires no end user interaction, so when the quickstart silently performs the transfer in the background and then gives you a button to view the details of the transfer you made, it's very unclear what's actually happening.

1. I kept the behavior where the authorization happens immediately after link, but I moved the creation action out to something that the user has to proactively do. However, I think maybe this was the wrong idea, and that I should have a separate button to authorize a transfer. The advantage of the current way of doing things is that it's less work and it's kind of foolproof (you don't have to have two separate buttons, one to authorize a transfer and one to create one), but also the button will only work exactly once because the authorization can't be re-used. That seems like it might be kind of confusing. I think I should probably change this?
2. I considered removing /accounts/balance/get from the transfer quickstart as being misleading, because part of the deal with Transfer is that you don't have to call /accounts/balance/get. However, it does work and it's not pointless -- some customers do call it because they have more strict balance-based risk checks than are incorporated into the authorization model -- so I decided to leave it in.

[ToddKerpelman]

As per our conversation, I think either two buttons (with some UI saying "Often, these calls will be make sequentially on the rserver") or one single "Authorize and then create" button would be best.