TFM patching bug when multiple TargetFramework(s) tags with conditions are present

Microbenchmarks in Crank don't work for .NET 9.0 currently ([logs](https://dev.azure.com/dnceng/internal/_build/results?buildId=2321794&view=logs&j=75d9e29f-0f2e-5603-71e1-b4ced6dfbff3&t=ccba0c24-ff75-569c-b1fb-989a3e917eea&l=51)):
```
Command:
dotnet publish MicroBenchmarks.csproj ....
....
error NETSDK1005: Assets file 'C:\Users\ .... \MicroBenchmarks\project.assets.json' doesn't have a target for 'net9.0'. Ensure that restore has run and that you have included 'net9.0' in the TargetFrameworks for your project.
```

The reason for that is a bug(?) when Crank is patching the TFM: it changes the first `` tag to just `` (without `s`) -- however, Microbenchmarks project file has some additional logic that depends on `` (with `s`) tag value being set ([src](https://github.com/dotnet/performance/blob/b685a3f2e8381c872576aee81fc88730bbba0e9c/src/benchmarks/micro/MicroBenchmarks.csproj#L4-L8)):

```xml

$(PERFLAB_TARGET_FRAMEWORKS)

net462;net6.0;net7.0;net8.0
net6.0;net7.0;net8.0
```

-- which results in `` being set by this logic, essentially overriding the TFM patch Crank did. This, by chance, was "working" for 8.0, because `net8.0` was present in the resulted TFMs list, but it does not work for `net9.0`, which is not present there yet.

While Microbenchmarks could be updated to include 9.0 (I'm trying to do that in https://github.com/dotnet/performance/pull/3504), the problem with the patching itself might resurface again -- in other projects, or in Microbenchmarks for vNext.