Generalize RenderEngineGl's geometries and instances

[SeanCurtis-TRI]

Previously, RenderEngineGl would assume a great deal about the geometries and how they get posed in the world. This changes those assumptions:

• Geometry primitives are no longer assumed by RenderEngineGl::RenderAt().
  • Each OpenGlGeometry records the nature of its primitives and that is used at render time.
• The vertex attributes can be organized more generally in a dat array. I.e, rather than the previous hard-coded grouping, a source could choose to present them interleaved (this can happen in future glTF parsing).
  • Each OpenGlGeometry stores the interepretation of its vertex data as stored in the associated buffer object (to facilitate cloning).
• We no longer assume the OpenGlGeometry data is measured and expressed in a frame that only differs from Drake's geometry frame by an optional scale factor.
  • A single Drake "geometry" can be comprised of multiple OpenGlInstances each with their own poses. And the underlying geometry can also have the vertex information expressed in yet another frame.
  • OpenGlGeometry and OpenGlInstance pick up new frame semantics to track this more general articulation of geometry.
  • This led to a redundancy in RenderEngineGl::Part, and that struct has been removed.
  • Shader programs have been updated to accept the various model transforms directly, rather than attempting to compute them on the fly.

Relates #20185 and #21520.

---

This change is 

[SeanCurtis-TRI]

+(release notes: none)

To see how this fits into the larger picture, see the overview PR in which RenderEngineGl consumes glTF files (#21520).

[ggould-tri]

geometry/render_gl/internal_opengl_geometry.h line 243 at r2 (raw file):

Previously, jwnimmer-tri (Jeremy Nimmer) wrote…

BTW The [GSG policy](https://drake.mit.edu/styleguide/cppguide.html#Variable_and_Array_Initialization) only requires member initialization for built-in types, not an Eigen type. The defect here would need to be something more specific like "too brittle of a footgun to live" or "confused about when this actually gets populated" or something like that.

Another of the many reasons to object would be "the default-initialized Matrix4f is not a homogeneous transform matrix as documented above".

[ggould-tri]

geometry/render_gl/internal_opengl_geometry.h line 87 at r2 (raw file):

Previously, ggould-tri wrote…

minor: Per the discussion below that these are 4x4, shouldn't this have four elements on the diagonal?

(whoops, that should be "1" instead of "0")