fix: normalize use of integers for notification IDs

[theproducer]

Scheduling a notification takes an integer ID, yet canceling a notification expects a string (and will do nothing if a integer is sent).
This PR brings consistency to the schedule and cancel methods, now requiring an integer ids for both operations.

closes #176

[jcesarmobile]

A bit of ancient history.
At the beginning, the local notifications plugin was iOS only and the identifier was a String, but when adding the Android implementation, Android only allowed integers, so it was changed to use number/integer both. But looks like the change was only made for schedule and not to the other methods, that kept using strings.

So if we are going to accept String as identifier, it should be documented that it only allows strings with numeric format, and Android code should be updated to accept those too. (This is only an Android limitation, on iOS it could use regular strings without casing to integer)
But even after this changes, schedule will allow a number or numeric string, but getPending will still return the identifier as string even if you used an integer to schedule it, which can be confusing (as it's now that returns a string)

So, I personally think that we should stick to allowing only number, but make getPending and other methods return the identifier as integer and not as string.

[imhoffd]

it should be documented that it only allows strings with numeric format

I agree. @theproducer can you add this?

we should stick to allowing only number, but make getPending and other methods return the identifier as integer and not as string

Agreed, but this is a breaking change for apps. This PR address this particular issue. We should definitely fix the architecture issues in a later release, but it will have to be a major version with documented breaking changes.

[jcesarmobile]

It’s a breaking change, but it’s technically a new plugin, so I think it’s the perfect time for doing it. Part of moving plugins out was to find design flaws and fix them and this is clearly a bug.

[imhoffd]

But we should try to minimize the amount of work app developers need to do when updating from v2 to v3.

Part of moving plugins out was to find design flaws and fix them

This may have been an early goal, but we started moving them over faster to save time. With the plugins moved out, we have the opportunity for app developers to migrate incrementally instead of all at once, and I think we should do that here.

[jcesarmobile]

Yeah, but in this case despite fixing it is a breaking change, it’s a bug fix after all, I don’t think we should avoid fixing it properly just to not break it. If you create a notification with an integer, you should be able to cancel it with an integer, making the user convert it to string makes no sense to me.

[theproducer]

Ok, I've gone ahead and made changes so that it requires / returns integers in both directions.

[imhoffd]

Can you change the PR title and description?

[jcesarmobile]

on iOS, when you schedule a notification it still returns the id as string
also when the notification is received and received listener is called, the id is also a string

on Android and web it's working fine