Touchpoints sometimes not reported released with the evdevtouch plugin typeB mtdev drivers

This happens in one particular case, and only with typeB drivers (which use input slots): when the touchpoint corresponding to the last slot is reported as released and a new point is reported as pressed right after, so that both events happens within a same sync. In this case, there will be two ABS_MT_TRACKING_ID events received, first with -1 to report the released touchpoint, then with a new id to report the pressed touchpoint, then the SYN_REPORT afterwards.

This situation results in the first touchpoint never being reported as released by the evdevtouch plugin, because it has been reported as pressed again by the time the sync is received, and the plugin only checks for pressed/released status during sync, but not what happens in-between syncs.

Here's an example of such a case recorded via the evtest tool (which records and prints out the same data that's being fed to the evdevtouch plugin):

```
Event: time 1448489993.576083, -------------- SYN_REPORT ------------
Event: time 1448489993.581145, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 0
Event: time 1448489993.581145, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 13629
Event: time 1448489993.581145, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 2
Event: time 1448489993.581145, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 14756
Event: time 1448489993.581145, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 10727
Event: time 1448489993.581145, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 3
Event: time 1448489993.581145, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 13246
Event: time 1448489993.581145, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 9675
Event: time 1448489993.581145, type 3 (EV_ABS), code 1 (ABS_Y), value 13629
Event: time 1448489993.581145, -------------- SYN_REPORT ------------
Event: time 1448489993.587005, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 0
Event: time 1448489993.587005, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1448489993.587005, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 1
Event: time 1448489993.587005, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10566
Event: time 1448489993.587005, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 10797
Event: time 1448489993.587005, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 2
Event: time 1448489993.587005, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1448489993.587005, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 3
Event: time 1448489993.587005, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value -1
Event: time 1448489993.587005, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 0
Event: time 1448489993.587005, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 267
Event: time 1448489993.587005, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 15240
Event: time 1448489993.587005, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 22029
Event: time 1448489993.587005, type 3 (EV_ABS), code 0 (ABS_X), value 10566
Event: time 1448489993.587005, type 3 (EV_ABS), code 1 (ABS_Y), value 10797
Event: time 1448489993.587005, -------------- SYN_REPORT ------------
```

Notice how slot 0 is present twice within the second sync cycle, first to indicate the touch point was released (tracking id == -1), then a new touchpoint was added to slot 0 again (tracking id == 267).

There's already a pending change to fix this bug: https://codereview.qt-project.org/#/c/125975/

but it's stalled since nobody in the review seems confident enough about the fix, despite my explanations and examples. Hopefully opening this issue will give it more visibility and interest in getting it merged.