[Grid] Introduce bitfield to dirty a subgrid's MinMaxSizes cache

This patch finalizes the reland of CL:5230717.

1. The key change this CL introduces to fix the regression that got it
   reverted is when to dirty `is_subgrid_min_max_sizes_cache_dirty_`.

   Previously, we dirtied this flag when we marked the intrinsic logical
   widths of a container as dirty. This ignored the case where the rows
   of a subgrid were standalone, since `ComputeMinMaxSizes` is not used
   to compute the intrinsic block size of a grid.

   Instead, this change marks the flag as dirty whenever a layout object
   or any of its children need to perform a relayout.

2. Removing the concept of only reusing the `MinMaxSizes` cache of a
   subgrid within the same step of the grid sizing algorithm in favor
   of reusing it in the second pass or within different runs of the
   `ComputeMinMaxSizes` and `Layout` methods if possible.

3. To determine whether we can reuse the cache or not we rely on the new
   `IsSubgridMinMaxSizesCacheDirty` flag in `LayoutObject`, but this
   change introduces more logic that determines if the cache must be
   invalidated depending on whether a subgrid's subgridded tracks
   changed between calls to compute its intrinsic sizes.

Significant perf deltas:
  - nested-subgrid
    avg 239.234 runs/s -> 273.888 runs/s (14.5% better)

Bug: 40946243
Change-Id: Id041f9d100651c8c7f8af8c7a4056e6298513228
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5581760


Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Ethan Jimenez <ethavar@microsoft.com>
Reviewed-by: Alison Maher <almaher@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1312623}