* wording:
  Update instructions to be closer to what is in current web signup

Allows us to advertise support address, for eventual inclusion in Cheogram adhoc
bot help output.

Keep this deprecation message in so that users with this still in roster know
where bot has moved.

* pass-messages:
  Pass messages to and from the SGX

* web-register-start:
  Hidden command to allow jmp-register to start a web registration

This is the command jmp-register will use to tell use a certain claimed JID
wants a certain tel.  We relay that to cheogram and save in web_register_manager
the tel associated with the JID cheogram assigns to the target.

Rewriting the from/to as appropriate.

* create_customer_id:
  Create customer_id if it does not exist before we start registration
  Break out CustomerPlan
  Inject BackendSgx per customer

We had Plan and Customer but the relationship between the two lived
entirely in Customer, which was growing quite large. Break that
relationship out into its own concept and give it a name.

Instead of being a singleton that represents the entire relationship
with the backend, the object is now per-customer (since any meaningful
method requires a customer anyway for the from JID at least) and can be
delegated to directly from Customer.

* invites:
  Block repeated invite code tries by customer id
  Allow user to activate using invite code

So it's not as trivial to brute-force the space and find an open one. Limit is
10 tries per hour.

Checks if the code is available and marks it used, then activates. Tracks who
invited and who used in the table for later reward or punishment.

* set-forwarding-on-finish:
  Configure number for inbound calls

* import-to-catapult:
  Import newly-purchased numbers to Catapult

* show-ratecenter-during-signup:
  Show rate center during signup

* activated-users-to-finish:
  Test that registered users get the Registered step
  Already activated user goes straight to finish

Fetch from bandwidth so we can show it to the user, in case they happen to care.

If not registered, but activated, they must have paid but failed to get their
number setup. Maybe the number was already taken. Maybe they paid manually. In
any case we can skip all intervening steps and go straight to buying and
configuring their number for them.

Since we still use Catapult ("v1") for voice application, we need to import all
numbers there and set their applicationId to match.

Adds the settings to redis that jmp-fwdcalls will use to route inbound calls.
Not done by the sgx registration even though fwdcalls is currently a plug-over,
and of course won't be once fwdcalls dies so do it here.

* new-signup-credit-card-decline:
  Block repeated declines for 24 hours
  Handle credit card decline

Show user error on decline and give the chance to pick another card.

* new-signup-add-credit-card:
  Happy path for credit card signup
  Panic should work on any value for error
  Allow getting default payment method, not just index
  Object representing the backend SGX to use
  Stop polluting Object namespace with Blather DSL
  Work in the presence of em-synchrony
  Helper to allow ordering phone number from Bandwidth v2
  Helper to get a promise that resolves after N seconds
  Every payment kind will need the plan, so put it at the top
  Use registration pattern for Payment kinds
  Method to bill the plan of a Customer
  Use Forwardable for simple delegations
  Helper to allow using sync-style code in a Promise context
  New signup: go to web to choose credit card
  OOB helper
  Reject promise on stanza error
  Fix typo

Assuming credit card payment works, you can now activate a new account by paying
with one.

This is what should know about things like the customer id -> jid mapping, etc.

em-synchrony monkeypatches em-http when loaded. The old functionality is still
present, but under different method names.

Uses their gem which uses Faraday. Set Faraday to em-synchrony so their gem is
now using EventMachine but still sync so their code will work unchanged.  Wrap
all uses of the gem in EM.promise_fiber to get a promise back out of that.

Implement a poll helper that can wait until a new order is complete at Bandwidth
before continuing.  They support an HTTP callback method, but only global on
account? This is much easier to work with in our context.

Instead of a hard-coded case statement.

Bills their balance for the cost of one month of plan.
Activates the plan by insert into plan_log, unless already active in which case
extends current plan by one month.

This helper spins up a fiber and returns an unresolved EMPromise, then runs the
passed-in block inside the fiber and fulfills the promise with the result of the
block. Because nothing is looking for the Fiber to return it is free to act as a
trampoline for EMPromise#sync and other fiber-sync-style code that does not
block the EM reactor.

This step, if chosen, directs the user to the jmp-pay webapp to add a credit
card.  It includes an OOB element for use by user agents that can handle
that (possibly for webview embed, etc) with a note-based fallback as per XEP.
Once the user chooses "next" the code checks if they have actually added a card,
and if so continues to a yet-unimplemented step and if not repeats the
instruction to go to the web app.

https://xmpp.org/extensions/xep-0066.html

This result variable got renamed to registered