What problem does this solve or what need does it fill?

Our existing Frustum type is used for computing what cameras should see.

However, as this existed before the addition of our mathematical primitive types, it a) doesn't live in bevy_math like the others and b) is missing all of the standard expected functionality for it.

What solution would you like?

1. Move HalfSpace into bevy_math unchanged.
2. Move Frustum into bevy_math unchanged.
3. Implement gizmos for frustums.

1 and 2 should be done in a single PR. 3 should be done in a follow-up.

We can later add all of the other weird and wonderful things (random sampling, meshability) to these types if people think it's worthwhile, but those steps are the key things.

Once things are moved, we can look into changing naming, representation and so on. Those should be done in tightly scoped PRs, with aggressive benchmarking for frustrum culling performance. This is directly in the rendering hot loop: changes here have a high impact, for both better and worse.

Additional context

Raised on Discord. @superdump gave us rendering's blessing, as long as we don't regress performance.

The remaining bevy_render::primitives types should be moved / consolidated eventually, but gizmos for frustums is the motivating requirement here.