Cleanup consistency of position types in `bevy_window`

[Weibye]

What problem does this solve or what need does it fill?

When interacting with windows in bevy and positions thereof, bevy_window presents the user with quite a variety of units without too much clarity or direction on why:

// From WindowCommands
resolution: (u32, u32), // window resolution
logical_resolution: (f32, f32), // also window resolution
position: IVec2, // window position
position: Vec2, // cursor position
// From Window
physical_cursor_position: Option<DVec2>, // cursor position

Winit behind the scenes works in either Logical or Physical units for sizes and positions.

• physical meaning "physical pixels", usually in the form of u32
• logical meaning "logical pixels" which are f32 / f64 values and usually a helper type to define sizes before any scaling has been applied.

What solution would you like?

I think it would improve consistency if the end user of bevy was encountered with a similar interface. Either by reexporting winit's definitions or by building some new types better suited for bevy's userspace.

What alternative(s) have you considered?

Keep using native types such as vectors and ints to not clutter the userspace with additional types. Most new users will quickly become familiar with Vec2 / IVec2 so keep using that might be preferable? If yes, I'd prefer all tuples become vectors so that we don't mix them.

[LoipesMas]

Replacing tuples with vector types seems like a no-brainer to me, considering the fact that they are already used in such context somewhere else.
But I'm not 100% convinced on exposing logical/physical types, as it can be quite confusing (I sometimes get confused which one should be used when 😅). Unless there would be a good explanation in the docs, but I'm don't even know how it would look like.

[Weibye]

Related to #4960