But not block them

it mostly just confuses people

Create a new trust level "Cellar" that cannot call or text or
invite (simlar to Tomb, but semantically different and can pay etc).

This is now the default trust level until an account receives at least
one text "from a person". Accounts before a certain date are
grandfathered in to now get this level. Port ins will get to bypass this
because the reachability SMS reply will count as a text from a person.
Accounts invited in any way except a group code will also bypass Cellar.

The instructions on the payment form and the welcome message are both
updated to warn of this new restriction. Note that the welcome message
is conditional to only include the warning if it applies to the customer
by that point.

Texts from short codes or with links or codes or from support do not
count as "from a person". There is also a block list of numbers in redis
to restrict what numbers are "from a person". The number that got an
account past Cellar is stored for possible addition to the block list.

- `MigrateBilling` passes a string for a tel, previously causing
  NoMethodError when `Payment.for` says `product.price`
- Introduces a new MigrateBilling class in lib so that unit tests
  capture any changes that break this in the future
- Edit .rubocop.yml to exclude `when_ready` from
  `Lint/ConstantDefinitionInBlock`, which was raised just now because
  this commit touched sgx_jmp.rb . I think this is the best solution
  because those constants (`REDIS`, `DB`, etc.) are used as globals
  throughout the codebase. Since many of them require a running EM
  reactor, changing this would require extensive refactoring.

note: in `test/test_admin_command`, the "-removal was to satisfy
rubocop, which my pre-commit hook caught because it only runs rubocop on
changed files.

Sometimes you want to send a message to a handful of people...

to that end: make `SIMKind` easier to hold by making internals, as well
as the raw CONFIG[:sims] entry, protected

It doesn't do anything we need and causes us to need more config we'd
rather not have

- should behave identically to previous script if no rows found,
  manually running it just produces an empty array for
  `PortRepo::Db.list`, i guess our client knows about no rows errors
- allowed `OptionParser.new` to hold a huge block because this block is
  just naturally very large. Alternatively, we could write separate
  files just for argument parsing, eg `lib/bin_arg_parsers/{args.rb,
  parser.rb}`. But that's probably a separate ticket

problem was that AvailableNumber.for sometimes returned a promise,
sometimes not, causing us to try to call `catch_after` on a Tn