Improve geometry APIs, to be closer to euclid

[ids1024]

I want to update #1136, make any needed improvements upstream to euclid, and get that merged. But it requires a lot of changes both in Smithay and compositors using it. Perhaps adding some APIs and uses of the #[deprecated] attribute first could make that a little less painful to deal with.

Even if Smithay didn't move to euclid, it would be worth borrowing some ideas to make geometry handling more strongly typed, as well as a couple API conveniences.

[Drakulix]

This matches euclid::Rect's API, but it also seems a little better to
have strong typing without implicit conversion like this.

I am not sure I agree with this, when we are just adding into-calls everywhere. It just makes everything more busy. What is the future goal here to actually make use of that type-safety?

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 40.50633% with 47 lines in your changes missing coverage. Please review.

Project coverage is 19.34%. Comparing base (2eddf12) to head (5af799e).
Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
src/utils/geometry.rs	53.33%	14 Missing ⚠️
src/backend/renderer/element/texture.rs	0.00%	5 Missing ⚠️
src/wayland/compositor/handlers.rs	16.66%	5 Missing ⚠️
src/backend/renderer/element/memory.rs	0.00%	4 Missing ⚠️
src/backend/renderer/element/solid.rs	0.00%	3 Missing ⚠️
src/backend/renderer/mod.rs	0.00%	2 Missing ⚠️
src/backend/renderer/utils/wayland.rs	60.00%	2 Missing ⚠️
src/wayland/viewporter/mod.rs	0.00%	2 Missing ⚠️
anvil/src/render.rs	0.00%	1 Missing ⚠️
anvil/src/shell/mod.rs	66.66%	1 Missing ⚠️
... and 8 more

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1621      +/-   ##
==========================================
+ Coverage   19.33%   19.34%   +0.01%     
==========================================
  Files         171      171              
  Lines       28365    28363       -2     
==========================================
+ Hits         5485     5488       +3     
+ Misses      22880    22875       -5     

Flag	Coverage Δ
wlcs-buffer	16.84% <39.24%> (+0.01%)	⬆️
wlcs-core	16.58% <37.97%> (+0.01%)	⬆️
wlcs-output	6.83% <15.18%> (+<0.01%)	⬆️
wlcs-pointer-input	18.31% <37.97%> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ids1024]

I've added a Mul impl for Rectangle (which euclid has). This is useful in at least a couple places in cosmic-comp.

Where possible it seems best to use high-level operations like that on these strongly-typed geometry types instead of calls to things like Rectange::new, though I don't know how many of the use cases can be better handled with something like that.

I am not sure I agree with this, when we are just adding into-calls everywhere. It just makes everything more busy. What is the future goal here to actually make use of that type-safety?

Where we really want to get type safety is by using more coordinate spaces, distinguishing between points and vectors (it shouldn't be possible to add two "points" in the same space to get an element of that space.) And things like euclid::Translation2D. #1620 happens to be a good example of something we'd want to make statically impossible.

If we want to move to euclid, this change to match euclid::Rectangle::new will be necessary. That and renaming loc/w/h to origin/width/height account for a lot of the changes needed to compile with the euclid types (plus extension traits for to_physical, etc).

If we don't move to euclid, avoiding implicit conversion generally seems like a best practice. It's not a big deal, but there are a couple places where it's not obvious that the argument is a tuple, so we're asserting what coordinate space it's part of. In general it doesn't make things much worse. Something like euclid::rect could be handy when constructing a rectangle from four scalars (particularly in tests).

Though if that change is too controversial I can drop 5471a59 from this PR. The other small additions here seem useful.