Ensure target and currentTarget properties are set on events

[andybluntish]

We had a problem where a library was making XHRs and expecting event.currentTarget to be set to the XHR object in a readystatechange handler.

1. Set currentTarget on Events
   When listening for events (e.g. readystatechange) some libraries expect event.currentTarget to be set to the XHR, as well as event.target. Since the readystatechange event doesn't bubble, the target and currentTarget will always be the same.

2. Set the target for readystatechange events
   Ensure we can access the XHR via target/currentTarget when listening to
   the readystatechange event.

[stefanpenner]

This change requires corresponding tests

[andybluntish]

Thank you. I added some tests, please let me know if they're not sufficient.

Also, running the tests updated the built fake_xml_http_request.js file, but not the corresponding source map file. Is there a build step or a preferred way to update the source map that I'm not seeing?

[timiyay]

I'm picking this issue up, so I can move our company off our forks of FakeXMLHttpRequest, pretender, and mirage.

If we can get this issue fixed up, and bump all the versions so that the fix is available to mirage, then we won't need our forks.

@stefanpenner If you get a moment, are you able to review this PR? I can make any necessary changes from the review.

[BarryThePenguin]

Looking at Comparison of Event Targets on MDN

event.target

The DOM element on the lefthand side of the call that triggered this event, eg: element.dispatchEvent(event)

event.currentTarget

The EventTarget whose EventListeners are currently being processed. As the event capturing and bubbling occurs this value changes.

sinonjs also does a similar thing in nise

https://github.com/sinonjs/nise/blob/e2dc539f07ceda87e7434362e12d4446a917e894/lib/fake-xhr/index.js#L258-L262

I think this may even be related to #28?

[asppsa]

I've rebased this PR onto the current master and compacted the commits down into two: one for readystatechange events, and one for progress events. @xg-wang, we're happy to make whatever further changes are necessary to get this PR accepted.

[kaizau]

@stefanpenner Is there anything else preventing this PR from getting accepted?

This gets FakeXMLHttpRequest to behave more realistically, in addition to unblocking those of us who are relying on forks.