Fix touch input lag that occur on some devices. 

This is a bug that has been reported on many occasions. I have seen it myself on a custom AMDx86 tablet but on AtivTab is not visible. Others has seen it on Surface Pro and XPS10. 
This comment mono#2113 has been very helpful to track down this bug. It has been speculated that it is due to drivers firing events faster, or that on slow machines events are not consumed as fast. I would like to add the possibility that the quality of the touch screen might be a factor to why we see that on some devices and not on others. The better/more accurate a touch screen is, the more visible this bug is.

I had to close the previews PR f63da1f and resend after the recent changes on TouchPanel/TouchPanelState.

I will try to explain this as briefly as possible. 
TouchPanelState.Refresh(...) is always called inside a while "ex. (touchPanelState.Refresh(...) ) {...}" by making the assumption that this functions returns false when there are no more events to process. 
This function, for every preview touch id, goes through the event list and tries to find the first event with the same id, remove it, and break the loop. Then continues on with the next id and finally with the rest of the program.
In case the event hasn't changed position from last time and there are no other real events, stateChanged remains always =false and the function returns false. This breaks the caller's While() loop and wont be called until the next frame. The problem is that it removes one nonmoving event at a time while the list accumulate similar events for that id. 
The fix is that we keep removing events of that id, as long as stateChanged==false, which is all nonmoving events we can find until we reach a real touch event.
The j-- of course adjust the j indexer after the removal of one element.