sokol_gfx.h wgpu: fix up bindgroups cache when destroying associated resource objects

[floooh]

Fixes #1066: Whenever a sokol-gfx image, sampler, storage buffer or pipeline object is destroyed, the wgpu backend bindgroups cache will be scanned for entries which use that sokol-gfx resource. On a hit, the bindgroups cache item will be invalidated and the associated WebGPU BindGroups object released. The explicit calls to wgpuTextureDestroy and wgpuBufferDestroy have been removed since WebGPU's internal garbage collection takes care of destroying any in-flight objects when it is safe to do so.

A new entry has been added to sg_frame_stats which counts such bindgroups-cache slot invalidates, and sokol_gfx_imgui.h has been updated so that the new counter shows up in the debug UI.

• add an bindgroups cache invalidate counter to the wgu frame stats
• add dbg ui to dyntex3d-sapp.c (to check frame stats)
• update changelog
• remove the explicit resource destruction calls (wgpuTextureDestroy and wgpuBufferDestroy), this should take care of the problem mentioned below and also doesn't have any downsides anymore, since stale BindGroups are no longer a thing.
• merge dyntex3d-sapp.c: remove wgpu specific workaround sokol-samples#148
• deploy sample webpages

NOTE: even with the above changes, there's still the case where a sokol resource might be destroyed while its bind group is in flight. This is a tricky problem to solve - one solution would be a delayed-release-queue like in the Metal backend, but the 'inglight-pipeline depth' in WGPU is unpredictable (could use a very conservative value though).

[floooh]

PS: actually do it 'properly': the list of resources and their types is already stored in _sg_wgpu_bindgroups_cache_key_t which in turn is already stored in _sg_wgpu_bindgroup_t. This allows to figure out if a specific resource is contained in a specific bindgroups cache slot and invalidate only affected slots.