Improve event/callback logic for Push Notifications updates

[atsakiridis]

Right now we are using the following approach:

1. Init with success signaling, success in push configuration: return success after signaling is good, and then nothing when push configuration is successful
2. Init with error signaling, doesn't matter what happens in push: right after signaling is failed, return error and don't even try doing push configuration
3. Init with success signaling, error push: return status when signaling succeeds, and then, when push configuration fails return a warning

The problem with this is that:

• In (1), success only tells us about the signaling part which is a bit misleading as its not clear to the user whether they are really able to take full advantage of SDK.
• In (3), we get 2 consecutive statuses, which again is not very helpful from UI/UX perspective on how to convey the issue in a nice manner

Proposed approach:

1. Init with success signaling, success in push: wait until both signaling and push setting are successful and then return success
2. Init with error signaling, doesn't matter what happens in push: right after signaling is failed, return error and not even try doing push configuration (when those happen in parallel, we can leave it finish though, no point in killing it)
3. Init with success signaling, error push: don't return any status until you both are done, at which point we return a warning BUT using RCDeviceListener.onInitialized() and introducing a warning code
4. Update parameters when user changed a push notifications related parameter, convey status potentially by using onConnectivityUpdate(), also consider renaming it to something like onStatusUpdate(), so that it reports on changes both on signaling connectivity and push notifications status.
5. FCM token updated so push notifications configuration was updated internally. In this case we don't need to update the user (since the user didn't initiate the change), unless the update was failed, in which case we can return onStatusUpdate() accordingly.

Notice that it might make sense to introduce a simple FSM class inside RCDevice to take care of the transitions, without having to scatter checks in the whole codebase.