Add set_cursor_position method to Window

[smokku]

This allows programatically setting cursor position in Window.

[cart]

Now that we have logging set up by default, I think it makes sense to make these types of errors "soft errors" (ex: just use error!("Unable to un-grab cursor")).

I'd much prefer using "recoverable errors" when possible, but in this case the "command" has already been sent.

[smokku]

How do you suggest changing this error handling?

[smokku]

I'm not sure you can call these recoverable. If the game expects the cursor grabbed, it most probably won't work as expected with cursor ungrabbed.
Similarly game expects cursor to be at the set position and behavior when it is not may be unpredictable.

[ambeeeeee]

Potentially there could be a mechanic to set a WindowCommand to panic on failure (rather than print an error), so then it could be defined whether exclusive cursor grab (or other window commands) can fail gracefully in the context of the configuring application.

[cart]

While I'm sure some people would find that useful, adding a bunch of "knobs" like that have negative implications too:

1. more implementation complexity
2. more code paths. this makes the behavior harder to document, support, and understand

I think in this case we should just make a decision. It won't please everyone, but it will probably please 99.9% of people.

And if we're going to choose one, I think we should log it as a "soft" error. This is the sort of thing that will probably fail for "os support reasons". I don't think devs will want their games to crash because the cursor didn't lock. If someone must have WindowCommands panic in this case, they can register a new tracing subscriber that panics on incoming logs. Or (probably even better) we could create a new Events<WindowError> collection, which developers could consume to detect these cases.

[ambeeeeee]

If that's the way you would like to go then I support it. I especially support the soft errors, and the events would be a good way of doing it.

[smokku]

OK. I added error! calls, but I don't feel like adding the whole Events<WindowError> mechanics just to handle these unlikely errors. ;-)

[ambeeeeee]

I can do that if you want, as a different pr