Geometry classes may have unsound `noexcept` on their methods

Integer-based geometry classes (QPoint, QRect, QSize, ...) are susceptible of signed overflow and underflow, which is UB.

For instance QRect::width() returns right-left+1, and with right and left spaced enough, the subtraction will overflow.

Unfortunately a lot of these methods are marked noexcept, so I'm not supposed to put a Q_ASSERT (soon: Q_PRE, because this is 100% testable by the user before attempting the operation; these are glorified int holders) in them to warn the user that there's something wrong.

Should we get rid of these noexcept? If so, what's the API/ABI impact?

(The alternative would be to redesign these classes to properly handle these boundary conditions, but that's an even worse API break.)