Add support for Nexmo inbound SMS

[awslattery]

Previously, this library relied on Nexmo's SMS API/webhooks, however, as they no longer offer free inbound SMS processing, we made the determination to switch to a more robust and popular provider, Twilio.

As we'd like for this repository to be a bit more versatile for other uses, it'd be beneficial to add support for other telephony platforms, such as Nexmo, Plivo, and others that are requested and have notable market share.

As part of implementing this feature, it should incorporate:

• [ ] a check against the poll settings in Cloud Firestore, which will include a parameter for defining which telephony provider is used (currently, the IdeaFunding 2019 poll is set to "twilio"); a mechanism by which to switch payload handling based on the defined provider
• [ ] the necessary additional code/refactoring to support Nexmo's webhook payloads

and, ideally, it should include:

• [ ] a test case for successful vote insertion
• [ ] a test case for a bad payload (e.g. missing param, malformed data, etc.)

[stackswell]

Currently, a relevant poll is identified via the phone number to which an SMS payload is sent. This data, in itself, is extracted via the request payload. As such, accessing the data necessary to identify a poll and fetch it's config is dependent upon knowledge of it's payload structure. Perhaps, a more effective pathway to support configurable SMS provider would be by serving this config from a different location, perhaps Firebase Remote Config.

[awslattery]

perhaps Firebase Remote Config.

Remote Config isn't part of the official Node client libraries at this time, but they do have a RESTful API that could possibly be leveraged.

Perhaps we could isolate the functions responsible for casting the vote itself as an import, and create different endpoints for each service -- that way, a user could simply add a different webhook endpoint for each service?

[stackswell]

I am implementing this as an optional extra route parameter for alternative providers. Default will remain twilio. Available alternates will be dynamically populated from a sub-directory of vendor named utility files exposing functions for payload processing. As mentioned above, since the poll itself is identified from the payload contents, the poll record in the db is provider agnostic. For this reason perhaps we should remove the provider property from the db reference, as it will effectively serve no purpose.

I will be closing this issue via an upcoming PR. Documentation will come shortly thereafter.