What?

This PR adds notification polling, currently based on the heartbeat API from WordPress.

Why?

This attempts to solve the following issue: #306

How?

This PR adds a new Poller class that abstracts how/when/how often the notifications are polled.
It makes sense to use the existing Heartbeat API from WordPress since it is reliable. The Heartbeat API is a simple server polling API built into WordPress, allowing near-real-time frontend updates.
Heartbeat API Docs

The Poller class hooks into the heartbeat.tick event, which is triggered on a successful heartbeat (in case the user session expired or there is another error, we also skip useless polls to the API).

There is a parameter that is passed to the Poller class named shouldSkipFirstBeat which solves the following edge-case: we load all notifications on page load, but also on some pages, the heartbeat API runs very early on the page load (eg: on post edit/create screen, on post list).
To avoid double, repeated polls to fetch notifications, the first Poller.SKIP_FIRST_INTERVAL milliseconds, any heartbeat tick events are ignored.

The Poller instance is added to the notifications (window.wp.notifications) object, so you can easily do:

• window.wp.notifications.poller.stop() - Stop polling
• window.wp.notifications.poller.start() - Start/resume polling

Testing Instructions

1. Visit any page on wp-admin
2. Wait for a heartbeat tick event
3. Notice the polling request.
4. Visit the posts page. Check that only one call is made on page load.

I am open to suggestions and ideas, also if you want to use a setInterval/setTimeout instead of the Heartbeats API, let pe know. I think it is appropriate though.

Closes #306