[#223] Resolve "bulk invites"

Closes #223 (closed) and implements the behavior it describes

context

• new users like the boost!
• they wanna invite people to their channel!
• this would be hella easier if the INVITE command could be used to bulk invite a list of numbers, which is what this MR does!
• turns out the most complicated part of this MR is handling the fact that some elements of the list might be invalid or produce db failures while others might be valid or succeed. most of the work described below went to making sure we handle all failure permutations gracefully and give nice error messages about which numbers failed and should be reformatted/retried

changes

in commands.parse:

• expect a comma-separated list of locally-formatted numbers plus country code as input to INVITE payload
• attempt to parse an array of e164 phone numbers from list
• if any list elements cannot be parsed to valid e164 numbers, return parse error with message specifying which numbers should be reformatted
• if all list elements can be parsed to e164 numbers, pass Executable to next processing step

in commands.execute:

• assume payload to INVITE is an array of phone numbers (not a single phone number)
• attempt to record invites for all phone numbers
• if all invite processing succeeds, return a success message and notifications for all numbers
• if any invites have db errors:
  • return an error message that specifies which invitee numbers should be retried
  • return notifications for all invites that succeed (so they will be sent even if some invite have db eror)

in validations.phoneNumber:

• introduce a number of changes that make it easier to parse batches of phone numbers (by preserving the inputs that failed to parse so they can be displayed back to users so that callers no longer have to do this!)
• always return an input field with raw input (valuable if trying to return errors for array of validated results that failed)
• return null instead of stripped number if validation fails (because a stripped invalid number is both confusing and not useful for anything)
• eliminate isValid field (since we can infer invalid phone number from null phoneNumber field)

in dispatcher.run:

• handle the fact that ADD and INVITE now have different payload signatures in setExpiryTimeForFirstTimeUsers (ADD returns a single phone number, INVITE returns an array)

in tests:

• add some missing tests to exercise vouchedInviteReceived by adding a scenario where vouchLevel is greater than 1 (to make it possible to only user simpler/terser inviteReceived in other) tests
• refactor a bunch of junk to make sure translations/payloads are well-tested that i'm too lazy to write down here!