Issue-58: Ensure safety usage of the init_data methods

[chadell]

Addresses issue #58
Ensure try/except pattern for any issue found while initializing NotificationData from the library client, returning empty data.
I know it's too open, but because there could be multiple errors I tried to make it the simplest in the code instead of documenting all the potential exceptions each method could raise.

[glennmatthews]

What's the purpose of these init_data_* methods? They seem like just really thin wrappers around Notificationdata.init* methods - why would I call these instead of calling those directly?

[chadell]

What's the purpose of these init_data_* methods? They seem like just really thin wrappers around Notificationdata.init* methods - why would I call these instead of calling those directly?

Yes, it is really "thinner" than my initial idea, but the main purpose is to expose a method to the client to avoid it know about the internal library details/classes, so, instead of using NotificationData.init_from_email your could directly call init_from_email and you don't need to now, if you don't want, about NotificaitonData class, but as you say the wrapper is so light that is not adding any other value while it's adding duplicated code/tests.
After considering it, understanding the benefit of the simple method as not worth enough, I would consolidate to the class factory.