Item change tracking does not respect "Set" metadata partitioning

VS's fast up-to-date check has two concepts relevant to this issue:

- **Item change tracking** which ensures a removal from the set of inputs is considered a change to the project (which, due to globbing, would otherwise be invisible if only on-disk timestamps were used).
- **Input/output partitioning via "Set" metadata** which allows inputs and outputs to be grouped such that timestamps within any given group are considered independently from those in other groups. One use of this is in Razor projects, where views are compiled into a separate output assembly. Without this feature, a change to a view would update `MyProject.Views.dll` but not `MyProject.dll`, and the next up-to-date check would consider the project out of date because `MyProject.dll` is older than `MyView.razor`, for example. Another use is when compiling web front end resources such as TypeScript, SASS, SCSS, etc.

The current implementation does not partition items when tracking item changes. This is a problem that can lead to overbuild loops, negatively impacting productivity in some scenarios.

---

### Example

Given:

```xml

```

Consider this log:

```
1>FastUpToDate: Comparing timestamps of inputs and outputs in set 'Scripts':
1>FastUpToDate: Adding UpToDateCheckOutput outputs in set 'Scripts':
1>FastUpToDate: 'D:\MyProject\wwwroot\myproject.min.js'
1>FastUpToDate: 'D:\MyProject\wwwroot\myproject.js'
1>FastUpToDate: The set of project items was changed more recently (26/11/2021 10:16:40 AM) than the earliest output 'D:\MyProject\wwwroot\myproject.js' (26/11/2021 10:16:33 AM), not up to date.
```

In this case the project item change was not in the set of scripts. The scripts are up to date, meaning that repeated builds do not modify their outputs. In this state, a build will always be scheduled and build incrementality is broken.

The fix is to partition the item change tracking by set.