Restore renderer cost instrumentation lost in the 5.0 rewrite

There is no visibility into what a ComponentRenderer costs. For a ComboBox or Grid that renders a component per item, this is often the dominant cost of a page load and the main reason a UIDL response is large, and right now nothing measures it.

Also a 5.0 regression

The agent-based kit had ComponentRendererInstrumentation, which put advice on com.vaadin.flow.data.renderer.ComponentRenderer.createComponent and emitted a span Component creation with a vaadin.component attribute. It went away with the agent in the 5.0 rewrite.

Why the kit cannot do it today

ComponentRenderer.createComponent has no listener, callback or interceptor. Unlike data provider queries, there is no Flow SPI in flight for it either.

There is a partial shim for Grid and TreeGrid: both implement HasDataGenerators, so a DataGenerator can be attached and its generateData calls counted and timed per component. That measures the whole per-item JSON generation, renderer included, rather than the renderer alone. ComboBox does not expose it, since its generator is package private on ComboBoxDataController.

Proposed work

1. Ship the DataGenerator-based measurement for Grid and TreeGrid, which needs no Flow change, as vaadin.data.item.generate.duration tagged by component.
2. Decide whether to ask Flow for a hook on ComponentRenderer.createComponent. Worth revisiting once vaadin/flow#25262 lands, since that establishes the pattern for this kind of observation point.

Start at the DataGenerator integration points in Grid and TreeGrid, and compare their generateData calls with the proposed vaadin.data.item.generate.duration metric. Done means measurement is shipped for both components and tagged by component; separately assess whether ComponentRenderer.createComponent needs a Flow hook, considering vaadin/flow#25262.