Maya 2025 patches

[trevorvanhoof]

Maya 2025 uses PySide6 and shiboken6, so I had to try/except the imports to make it work across Maya versions.

I moved all Qt imports into widgets/widgets_utils.py and then imported that instead so this workaround only needs to happen in 1 place.
Additionally, because PySide6 moved a lot of things around between namespaces (QUndoStack to QtGui instead of QtWidgets for example), I opted to remove the namespace prefix everywhere.

The alternative would have been to identify every moved class and (in widgets_utils) reassign them to their old namespace in the PySide6 branch: QtWidgets.QUndoStack = QtGui.QUndoStack
But that seemed like a never ending task, and since all of Qt's classes are prefixed with a capital Q I think it is guarded enough against naming conflicts.

Resolves #11

[theRussetPotato]

Hi @trevorvanhoof, thanks so much for taking the time to get this working in Maya 2025. I've never been a big fan to import entire modules with * since I find it really hurts readability, so I might explore alternatives first. Regardless this PR will be a huge help 🙏. I'll move this onto a different branch so I'll happily approve it and push it through while I weigh my options.

[trevorvanhoof]

I understand the aversion to import *, and it is forbidden in most style guides and linters afaik.

The 2 main reasons against it that I am aware of may not apply though I would love to hear why (else) it may not be a good descision; for self improvement reasons at least.

1: naming conflicts
by importing all we publish every name in the module which may not only introduce conflicts today; but it may introduce conflicts when updating qt and new names get added
This to me seems safe-ish because if the capital Q prefix (and why I don't do this for shiboken)

2: Import time code evaluation can be unexpectedly slow
Because PySide is a thin wrapper of a cpp library importing all is not going to execute much code so it is fast enough to just go for it (imo)

A middleground optiom I would be happy to put another PR in for is: import * in a qt.py file for ease of use (like I do now), and then import qt and prefix everything like 'qt.QPushButton' to have at least some namespace in the whole codebase to protect against conflicts

@theRussetPotato would that work?

[theRussetPotato]

@trevorvanhoof
Points 1 and 2 are good reasons to avoid it, though I mostly agree these shouldn't (hopefully) be big issues here.
What irks me more is that it tarnishes readability - objects are being created but it's not clear where they come from. Instead of being something that can be identifiable at a glance, you have to actually dive in to see its source.

I can understand the reasoning though, so maybe it makes sense in this case, or maybe not. Thus why I wouldn't mind seeing if there's something else to make it more explicit. Hope that makes sense!