Always allow userId override with explicit argument

[Munter]

This changes behavior to always prefer a passed-in userId over any persisted user id.

We've seen situations where race conditions can lead to en error being thrown by our SDK when following segments recommended approach to logging out:

analytics.track('Signed Out');
analytics.reset();

The bucket SDK can be reset before the event get tracked, which currently throws because only the persisted userId is taken into account, despite segment actually providing a userId explicitly in the bucket.event()-call

There is a possible discussion to be had on the behavior where both a persisted userId exists and an explicit userId is passed along. In this PR I treat the userId argument as authoritative, but we might want the behavior to be preferring the persisted userId if one exists

[roncohen]

@Munter should we get this in?

[Munter]

@roncohen I'll merge now. Just wanted to be sure there was no controversy with choosing the userId arg to be used as an override for a possibly available persisted userId

[Munter]

What semver bit should we flip on this? I'd say it's a bugfix, so I'd just do a patch release on it