Snap gizmo orientations to the current grid

For a few gadgets this works as expected. For a lot of them it doesn't, which can be super-duper frustrating.

Through testing I've found the following gizmos have strange rules dictating how the gizmo's direction can be set while the grid is on: (For reference, the "default grid orientation" is when the grid hasn't been changed. It's not the current grid or the grid of an object or anything. It's the purely default scene grid.)

The following only use the default grid orientation: tag, controller sensor, grab sensor(grab point), angle sensor, laser scope, mover, advanced mover, rotator, advanced rotator, emitter.

The following only use their associated object's grid orientation: gyroscope, look at rotator, rocket rotator, teleporter, force applier (directional).

Movement sensor: With local space off, uses the default grid orientation. With local space on, uses the associated object's orientation.

Doorways (spawn direction) and Camera Pointers: Grid-snapping the gizmo dot changes the arrow's orientation to current grid. But grabbing the arrow uses the default grid orientation.

Sun & Sky (stalk): The sky ball's centre isn't on the grid, and we cannot move it independently to be on-grid. Stalk uses current grid, but when dragged it moves the position along the stalk we’re dragging on-grid. The stalk then uses is a direction drawn from where we grabbed it (on grid) to the centre of the sky ball (not on-grid)... which is never perfectly on-grid unless the stalk points directly above or below the sky ball. So it is impossible to orient it to match the current (or any) grid properly.

Running into these caveats can be very frustrating, because the workaround is so inconvenient and may mess other things up. The workaround is to orient the gadget (or containing chip/associated object, etc.) onto the default grid, changing its position, orientation, and in some cases scale. Then setting the orientation of the gizmo relative to that object. Then trying to put the object back to how it was, getting the position, rotation, and sometimes scale the same as it was before.

In some instances, getting it perfectly the same as it was before may be very important to the working of the rest of the object. It may be possible to leave a proxy object in place before moving the real object to use the default grid, but not always.

In any event, this is super fiddly and annoying to have to do, and that's if the creator even realises what's causing the problem and that this workaround would help them at all. So, many just give up thinking it's a bug and they can't make their game, or they don't use the grid and just eyeball it which isn't good. In the few cases people think there may be something they're doing wrong and look for help, the only help we can give them is this janky workaround.

The expected behaviour would be that all things, objects, gizmos, everything, use the current grid. That's what it's there for. Without the different grids/orientations being forced, we can still always use the grid of an object if we choose it. And we can use the default grid orientation if we choose it.

If the creator chose to have the grid on, and have an orientation other than what is currently forced, that's a clear indication that they want to use that grid orientation. If they didn't, they'd set a different orientation, or turn the grid off. And the expectation has already been set by how everything else responds to the grid, so ideally it would just match that throughout, including these gizmo directions.