Remove dummy() from WindowId and DeviceId and use Option<DeviceId>

[daxpedda]

This was discussed in the last meeting but it was so late only @kchibisov and myself were around so I'm gonna re-iterate what we discussed here.

WindowId, DeviceId and the newly added FingerId, have only one purpose: making sure that users are able to differentiate between events coming from different devices.
dummy() however entirely circumvents this property, because it is always equal itself. Ideally dummy() would never be equal itself, but that's not possible while we want to implement Hash (unless we add a counter ...).
This is in a similar vein to #3795.

However, this assumption was made under the fact hat adding Option<DeviceId> was not necessary because only Web is using dummy() internally. Turned out this isn't exactly true: every backend has at least some events where it is unable to emit a unique DeviceId for a device. Some backends, like Wayland and Orbital, don't use any DeviceId at all, making all devices appear equal!

So with that in mind, I also replaced all DeviceIds with Option<DeviceId>.
Surprisingly enough this wasn't necessary for FingerId because every backend that implements touch emits a proper finger ID.

Based on #3795.

[madsmtm]

I think dummy() on WindowId was mostly useful back when we had Event::WindowEvent(WindowId, WindowEvent), and users wanted to create Event for testing.

[madsmtm]

Still need to remove this and other fn dummy().

Or do we use it for testing anywhere that I don't know about?

[daxpedda]

We have some tests that check if things don't panic:

winit/src/event.rs

Lines 1166 to 1173 in 7fbc211

	let did = crate::event::DeviceId::dummy().clone();
	let fid = crate::event::FingerId::dummy().clone();
	HashSet::new().insert(did);
	let mut set = [did, did, did];
	set.sort_unstable();
	let mut set2 = BTreeSet::new();
	set2.insert(did);
	set2.insert(did);

But it will be removed eventually when we split the backends out.
I'm happy to remove it now?
Eventually integration tests should check this sort of thing without requiring a dummy implementation for us: #2866.

[madsmtm]

I don't see that much value in that test compared to the many extra functions that we need to make it work - but I don't have a strong preference either way here.

[daxpedda]

I feel the same and would be in favor of removing it.
Unless I hear disagreement I'm gonna go ahead with that when the PR is ready.