Fix dangling ptr by introducing viz::TracedValue::Id

viz::TracedValue::AppendIDRef and SetIdRef took a void* for the ID.
Sometimes users of these APIs, such as RasterTaskImpl, would store void*
for use to provide to those APIs. An example of this is the
tile_tracing_id_ field in RasterTaskImpl, which has raw_ptr to a Tile
object for tracing purposes. This specific instance was identified as a
dangling ptr.

For this instance, during tests such as the
CommitToPendingTreeLayerTreeHostImplTest tests, the pointer become
dangling during the destruction of LayerTreeHostImpl. The d'tor would
call ReleaseLayerTreeFrameSink(), calling ReleaseResources() and causing
PictureLayerTiling destruction. The tiling's destruction would trigger
Tile objects destruction during TileManager::FinishTasksandCleanUp().
Doing so leaves RasterTaskImpl::tile_tracing_id_ referencing Tile
objects that no longer exist, triggering a dangling ptr error in
RasterTaskImpl's d'tor.

Rather than fix this via a RAW_POINTER_EXCLUSION, as the pointer is only
used as an ID for viz::TracedValue, this change introduces
viz::TracedValue::Id for use specifying an ID to calls into TracedValue.
Internally, this is just a uintptr_t with a convenience c'tor that
converts from void*. Callers that previously held onto a void* instead
store one of these new Id instances, avoiding dangling ptr concerns.
This change also modifies the signatures, and call sites, of the
TracedValue methods to use the new Id type instead of void*.

Low-Coverage-Reason: OTHER behind disabled by default tracing
Bug: 40212619
Change-Id: I3bb4e8a9e0f799d78be5fdda5da880a04fa48c64
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6700324
Commit-Queue: Sam Fortiner <samfort@microsoft.com>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1484382}