Set pointer capture on pointerdown on picker input

[NavidZ]

Chrome 73 starts sending click even to the common
ancestor of down and up events even when one was
inside the input element and the other one was
outside. This caused this library to fail in the
following scenario:
User presses down on the picker input which causes
the date picker and overlay to be shown. When user
releases the button the overlay gets the up event
and the common ancestor of these elements will get
the click. Since there is a click handler on the
document to close the popup, the calendar popup immediately
closes.

Using pointercapture API to capture the rest of the
pointerevents stream to the picker input it ensures
the click event target is the picker input and that ensures
the click handler doesn't dismiss the popup.

[NavidZ]

@colinhowe FYI as he was the author of the original CL.

This CL addresses #1165 in a more spec compliant way.

@DanielRuf I fixed the test here. The slow test assumed that the click goes to a parent node. But with the pointercapture API it guarantees that it is not the case.

Just as a note I believe this is a more web standard compliant way of what this library tries to achieve. The previous patch was again relying on an unspecified behavior of UAs and hence was at the mercy of the user agent on how to send the click events when user presses middle button while left button is depressed.

If you still believe this is not a proper behavior for this library feel free to close this again. I just sent this PL since you asked me to send one that addresses the comments I had here.

[colinhowe]

Thanks for pinging this to me. I was not aware of the pointer capture API!

Regardless of whether this is a regression or not in Chrome - this is a nicer change-set than the one I pulled together.

I'm still on the fence as to whether the change in Chrome is a regression or not. I'd say that the spec itself is slightly ambiguous about what the behaviour in these scenarios should be.