This PR uses requestPointerLock's unadjustedMovement option to enable raw mouse input in full-screen free flight mode.

• Chrome supports reading raw mouse input when pointer lock is used, and it seems to be generally recommended for first-person controls to make the mouse movement's relation to your looking angle more predictable: https://web.dev/articles/disable-mouse-acceleration.

• This setting also happens to work around a Chrome bug I encounter very often. When using free flight mode in Chrome, I noticed sometimes while I looked around with the mouse, over a single frame my viewpoint would suddenly rotate far, leaving me disoriented looking in a completely different direction. I debugged this by making MouseRotateControls.onMouseMove log the values of evt.movementX, and I noticed the issue was caused by evt.movementX suddenly having an extreme value like -720 out of nowhere instead of its normal range of values (roughly -40 to 40). I get an incident like this about once a minute when looking around a lot in Chrome, and never in Firefox.

  I found that this is a commonly known issue in Chrome (Add binding for requestPointerLock option unadjustedMovement: true wasm-bindgen/wasm-bindgen#3862, PointerLockControls broken in update of chrome? mrdoob/three.js#12757, Mouse jump glitchy problem with Chrome Win10 360 spin keep moving mouse to right. Triang3l/WebQuake#37, https://issues.chromium.org/issues/40547981), and this issue can be worked around by using requestPointerLock's unadjustedMovement option. It's convenient that the option that's good for first-person controls also happens to be the one that fixes this problem.

I am getting (on chrome w/ linux mint) this error with this change:

And the pointer-lock is not aquired.

So i am guessing there'd need to be some fallback ..
Also on how many browsers have you tested this? Does it still work fine on all browsers? My worry is that it (when it is supported and doesn't throw an error) could mess with the sensitivity on some systems :)

Whoops, I thought the worst case scenario was that a browser that didn't recognize it would ignore it (which was the behavior I saw in Firefox), but apparently browsers that recognize the option may not always support it. Now that I re-read https://web.dev/articles/disable-mouse-acceleration more carefully, I see that they have an example trying again without the option if it failed with it. I've adapted this PR to do that.