meshes, 3D meshes, and lights, for performance.

This commit splits `VisibleEntities::entities` into three separate
lists: one for lights, one for 2D meshes, and one for 3D meshes. This
allows `queue_material_meshes` and similar methods to avoid examining
entities that are obviously irrelevant. In particular, this separation
helps scenes with many skinned meshes, as the individual bones are
considered visible entities but have no rendered appearance.

Internally, `VisibleEntities::entities` is a `HashMap` from the `TypeId`
representing a `QueryFilter` to the appropriate `Entity` list. I had to
do this because `VisibleEntities` is located within an upstream crate
from the crates that provide lights (`bevy_pbr`) and 2D meshes
(`bevy_sprite`). As an added benefit, this setup allows apps to provide
their own types of renderable components, by simply adding a specialized
`check_visibility` to the schedule.

Currently, this provides minimal performance benefit in `many_foxes`,
but on top of binning (bevyengine#12453) it provides a 20% end-to-end speedup on
that benchmark.

* `check_visibility` and `VisibleEntities` now store the three types of
  renderable entities--2D meshes, 3D meshes, and lights--separately. If
  your custom rendering code examines `VisibleEntities`, it will now
  need to specify which type of entity it's interested in using the
  `WithMesh2d`, `WithMesh`, and `WithLight` types respectively. If your
  app introduces a new type of renderable entity, you'll need to add an
  explicit call to `check_visibility` to the schedule to accommodate
  your new component or components.

…tities

…tities

…tities

…tities

…tities

…tities

…tities