api: add DeviceId::{into,from}_raw

[kchibisov]

The same as for WindowId.

This also removes the internal platform ID.

--

I'm not sure what type to pick here, since some use u32, some i32. I think i64 would be the best, but then, negative values for DeviceId are strange?

Also, it's not that clear to what IDs should be limited.

For now I'm just using u64.

[daxpedda]

Whats the reason for introducing the methods? I would prefer keeping it opaque for the same reasons discussed in #3795.

[kchibisov]

@daxpedda we need a way to build those types when backends will be split.

[kchibisov]

I can make those functions private for now, but they'll be public eventually...

[daxpedda]

@daxpedda we need a way to build those types when backends will be split.

No, we can have Winit introduce its own DeviceId type that wraps this one to keep it opaque.
This problem was discussed in the last two meetings.

Generally speaking I'm always leaning towards making compromises internally rather then on the public API, which is to me the most important part of the whole project.

I'm in favor of keeping them private as long as the types are still in the winit crate.

[kchibisov]

I mean, if the core types are in winit-core including DeviceId, I'm not sure how you'd create one without e.g. Box or something like that.

Like with a layout like

// winit-core

pub trait DeviceEventHandler: ApplicationHandler {
    fn device_event(&mut self, device_id: Option<DeviceId>, event: Event); 
}

// winit-wayland
{
     // Should be `DeviceId`, but no way to build?
     state.device_event(device_id???, event)
}

It's true that if you re-export everything possible inside the winit and wrap everything, you can probably avoid certain things, but however you can not create traits with types like that, or at least there still should be a type that can be build from e.g. u64.

Unless you just do dyn, but dyn for Id doesn't make any sense.