Do not allow send_message to be passed nils in data hash (#32)

[pirogoeth]

This solves #32, but I'd like to get some second opinions before merging this.

[lukebooth]

I think this is ok, but I also think the person who made the issue maybe should prepare their data better with something like params.fetch(:bcc, "").

Forcing some kind of standard for a library isn't uncommon — you get an Exception thrown if you pass Nokogiri's parser nil. I think they just expect you to give them something they can work with instead of trying to guess and rescue from all the possibilities that can be sent to the parser.

¯\_(ツ)_/¯

[pirogoeth]

@lukebooth Yeah, honestly this doesn't feel quite "right" to me. I mean, it definitely solves the issue but I do agree that data should be prepared better before throwing it to send_message. I am also open to better ways of handling nils passed in data to send_message.

Although if this is the way we choose to do this, we have to make sure that the MessageBuilder and BatchMessage builder handle nils in a similar way. :\

[pirogoeth]

So this took a change in direction. After a discussion with @atarola we decided that while allowing the data hash in send_message to be nil was an okay solution, it could very well introduce silent issues if a parameter was accidentally unset and unchecked. So now, keys and values in the send_message data hash must not be nil otherwise a ParameterError will be raised.