Resolve #131 "UX Bug: fix confusing responses to incoming messages"

Closes #131 (closed) and satisfies the acceptance criteria listed in its #Behavior section (reproduced below) to provide sensible responses to all incoming messages regardless of the senders subscription status or the status of hotline messages (enabled/disabled) on the channel.

Additionally, it:

• strips channel headers from all command responses. now we only show them in broadcast messages and hotline message notices.
• adds a section to the INFO command response that tells a user whether they are subscribed to a channel or not (and if not, prompts them to subscribe).
• lays the groundwork for #140 (closed) by starting to use "hotline messages" everywhere in developer-facing names (though defers changing user-facing names until playing #140 (closed))

Behavior

GIVEN an UNSUBSCRIBED user sending to a channel with RESPONSES ON:

• WHEN user sends HELP or INFO
  • THEN user receives the appropriate command response
• WHEN user sends any other command
  • THEN user receives Your message could not be processed because you are not subscribed to this channel. Send HELLO to subscribe.
• WHEN user sends any non-command
  • THEN user receives Your message was anonymously forwarded to the admins of ___. Please include your phone number if you want admins to respond to you. You can also send HELP to list valid commands.

GIVEN a SUBSCRIBED user sending to a channel with RESPONSES ON:

• WHEN user sends a command that they are authorized to send
  • THEN user receives appropriate command response
• WHEN user sends a command that only admins can send
  • THEN user receives a message that says Sorry, only admins can issue that command. Send HELP to see valid commands.
• WHEN user sends a non-command
  • THEN user receives Your message was anonymously forwarded to the admins of ___. Please include your phone number if you want admins to respond to you. You can also send HELP to list valid commands.

GIVEN an UNSUBSCRIBED user sending to a channel with RESPONSES OFF:

• WHEN user sends HELP or INFO
  • THEN user receives the appropriate command response
• WHEN user sends any other message (including all other commands)
  • THEN user receives Sorry, incoming messages are not enabled on this channel. Send HELLO to subscribe to announcements.

GIVEN a SUBSCRIBED user sending to a channel with RESPONSES OFF:

• WHEN user sends a valid command
  • THEN user receives appropriate command response
• WHEN user sends a non-command message
  • THEN user receives Sorry, incoming messages are not enabled on this channel. Send HELP to list valid commands.

Implementation

• add more segmented versions of unauthorized (ie: notAdmin and notSubscriber)
• strip headers from command responses (eliminating the need to call format all the time in confusing ways)
• renames variables referring to "subscriber responses" or "broadcast responses" to variables referring to "hotline messages"
• adds a commandResponse.hotlineMessagesDisabled string and adds two variants for commandResponse.hotlineMessageSent string (which vary according to sender membership status)
• add 3 variants to commandResponses.info (that vary according to membership status)
• add more granular unit tests for translation completeness:
  • test 2 layers of nesting inside messages.commandResponse not just 1
  • provide it statements that point to specific missing translation for easier test fixes