Problem

In Bevy, there are currently:

1. https://dev-docs.bevyengine.org/bevy/a11y/accesskit/struct.Rect.html: f64, re-exported as part of our a11y work
2. https://dev-docs.bevyengine.org/bevy/math/struct.Rect.html: f32, used in UI
3. https://dev-docs.bevyengine.org/bevy/math/struct.URect.html: u32, used in UI
4. https://dev-docs.bevyengine.org/bevy/render/primitives/struct.Aabb.html: f32 3 dimensional axis-aligned bounding box, used in rendering
5. https://dev-docs.bevyengine.org/bevy/math/bounding/struct.Aabb2d.html: f32, 2 dimensional axis-aligned bounding box
6. https://dev-docs.bevyengine.org/bevy/math/bounding/struct.Aabb3d.html: f32, 3 dimensional axis-aligned bounding box
7. https://dev-docs.bevyengine.org/bevy/math/prelude/struct.Rectangle.html: f32, a mathematical primitive 2d shape w
8. https://dev-docs.bevyengine.org/bevy/math/prelude/struct.Cuboid.html: f32, a mathematical primitive 3d shape
9. https://dev-docs.bevyengine.org/bevy/ui/struct.UiRect.html: not a rectangle! Instead, used for things like padding

Please let me know if I've missed any.

We don't need this many distinct types for a rectangle! This results in user confusion, inconsistencies, duplicated API surfaces and more.

Proposed changes

1. Don't re-export a11y types.
2. Eliminate bevy_render::Aabb in favor of the bevy_math types. Needs benchmarking.
3. Remove the Rect used by bevy_ui in favor of Rectangle.
4. Consider how we want to handle integer versions of geometric primitives and do so cohesively.
5. Investigate if we need distinct Aabb types, and if we do clearly document on them why just using a Rectangle or Cuboid isn't good enough.