Allow multiple apps v2

[djih]

Adding support for multiple apps. This is an backwards-compatibility-breaking change.

Changes:

1. Refactored utm handling into its own module
2. Refactored default options into its own module
3. Refactored Amplitude logic into AmplitudeClient module
4. Added instance handling in Amplitude, mapped old Amplitude methods to new default instance methods
5. Combined all cookie/localstorage upgrading logic into one function, only run for default instance
6. Copied Amplitude unit tests to AmplitudeClient unit tests to test instance methods. Added tests for cookie and local storage upgrade on default instance
7. Kept Amplitude unit tests to test for backwards compatibility on public methods. Added tests for separate instances
8. Update Amplitude-Snippet, index to handle proxying on instances
9. Update Readme to explain v3.0.0 change, how to log events to multiple apps, etc
10. Added helper method to see if apiKey has been set

Notes:
API Change:
Amplitude now functions as an instance manager, like what we already do for iOS and Android SDKs. You call Amplitude.getInstance() to fetch a default instance if you want to log events to a single Amplitude App. Updated Readme examples to use this notation. To have separate instances, you assign names to each instance and call Amplitude.getInstance('instance_name') to fetch separate instances.

Existing public methods on Amplitude (logEvent, setUserProperties, etc) are deprecated, but have been mapped to Amplitude.getInstance() equivalents, so they are still usable. Javascript supports object pointers, so we are able to have Amplitude.options point to Amplitude.getInstance.options. Private properties on Amplitude (such as _sessionId) no longer work. Users will need to change references to be on the default instance, for example: Amplitude.getInstance()._sessionId.

The default instance is backwards compatible with existing data. Users who are staying with 1 app should continue using default instance.

Updating cookie data:
To support different settings for different apps, each instance needs its own cookie, so we append the instance name as a suffix to each instance's cookie name.

The default instance continues to use the old cookie name. To maintain backwards compatibility on the default instance, we need to consolidate all cookie data. In cookies we store deviceId, userId, sessionId, lastEventTime, eventId, identifyId, sequenceNumber. We need to migrate all of those values from 3 possible cases:

1. Users updating from before v2.7.0: some of those values are saved in localStorage, so we check there for values.
2. Users updating from v2.6.0: that is the version where we attempted to migrate deviceId and userId to localStorage, but found that it broke across subdomains. So we have to migrate those values back.

Updating localStorage keys
We save unsent events to localStorage. To support different apps, we also need to append the instance name as a suffix to the localStorage key names. Like with cookie, the default instance will use the old localStorage keys for backwards compatibilty.

Proxying in the snippet:
We keep the existing Amplitude._q queue, which handles the deprecated public methods on Amplitude. We add a Amplitude_iq = {}, which keeps a mapping of instance names to objects that have their own _q queues. In index we move all the _q to their appropriate instances, and then in runQueuedFunctions we playback all function calls in Amplitude._q and all the function calls in each instances _q.

This feature needs to be released in tandem with a product email update so that people are aware of the API breaks.