Move Bandwidth Tn remote operations to BandwidthTnRepo

Merge branch 'nuke-legacy-customers'

* nuke-legacy-customers:
  Remove LegacyCustomer

Remove LegacyCustomer

Such customers are not longer a common or valid case.

Merge branch 'rubocop'

* rubocop:
  Additional fixes for rubocop 1.10.1
  Switch to rubocop 0.89.1

Switch to rubocop 0.89.1

This is the rubocop in new Debian stable

Merge branch 'configure-calls-v2'

* configure-calls-v2:
  New configure calls command
  Move more persistence into the repo layer
  Easy DSL for adding XEP-0122 validation to fields
  CustomerFwd uses ValueSemantics, translates old XMPP-SIP URI

Move more persistence into the repo layer

BackendSGX shouldn't touch Redis, instead get one of the repos to save the data
we want saved wherever that repo saves it (in this case, those same Redis keys).

Move CustomerFwd behind Customer

All the previously-lazy BackendSgx data is now either all loaded or all not
loaded by swapping the sgx_repo used by your CustomerRepo instance.  When not
loaded the fields are filled with bottom values that explode when used.  When
loaded the values are present in RAM and not promises at all.  Most code paths
do not need any of the data, a few need most of it, so this seems like a good
trade-off.  Most code using this object will simply never touch those fields or
care about how they are loaded, etc.

Of course, most of this data isn't even SGX related and should move out of here,
but that would take a data model refactor/migration on the catapult_* schema.

Customer Info

This should allow us, the admins, to query information about a customer
without having to dive in and run a couple redis queries and some
database queries before getting the full picture of who we're talking
to.

It also allows the users to request some data about themselves. Balance and
phone number are already visible in other places, but their expiry is currently
not, and people have been asking about it.

Remove BigDecimal.new

It turns out in newer versions of Ruby this isn't cool anymore.
The new way is BigDecimal(value), which is dumb, but whatever...

Customer always has a JID

Factor out CustomerRepo

Using the Repository pattern to encapsulate the fetch and create operations on
the persistence layer for a domain object.  These were not really factories in
the classic sense, but rather "fetch from persisitence layer" methods, and so
they now have a home.