Provide whitelisted event initializer

[rclee]

This PR will add a generic event initializer to allow for faster iterations of new events. The main purpose of bringing this out now is our performance push and the need for many new events to be added and sent quickly.

Caution should be used when using this initializer. Such as enabling debug mode on eventsManager and ensuring your events make it to the server. Failure to do so could result in a loss of telemetry data.

[codecov-io]

Codecov Report

Merging #93 into master will increase coverage by 0.03%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #93      +/-   ##
==========================================
+ Coverage   77.28%   77.32%   +0.03%     
==========================================
  Files          81       81              
  Lines        3782     3792      +10     
==========================================
+ Hits         2923     2932       +9     
- Misses        859      860       +1

[julianrex]

Just a couple of questions here (which I think we've talked about before briefly):

1. Why is this a class method rather than an MMEEvent initializer? Is this for future support for different MMEEvent subclasses? So does this mean -[MMEEvent init] is essentially "private"? If so, I wonder if it's worth having a specific initializer (in addition) and marking the default init as NS_UNAVAILABLE. Thoughts?
2. Should this method take an NSDate rather than a date string? Perhaps a date transformer could be supplied (somewhere).

[rclee]

This PR is somewhat of a stopgap measure until we can completely remove the whitelisting that is currently in place. The doc describes some of those plans and how we might accomplish them.

1. I'm not sure how the decision came about to make these class methods or what the future plans were for it. I don't see any harm in a user of the library using an initializer vs any of these class methods to construct an event however. Is there something I'm missing here?
2. I agree that this could be provided in another way and potentially better way (especially once we implement date/time correction {insert Doctor Who meme}) but I think that should be done a little further down the road. For now the date string is supplied by the eventsManager via MMENSDateWrapper and all that needs to be called by the client/host is enqueueEventWithName:attributes:.

[julianrex]

Is there something I'm missing here?

No - more curious about future plans 😄

[...] but I think that should be done a little further down the road

Thanks for clarifying 👍